MoSCoW Prioritisation: A Working Guide with Templates

MoSCoW is easy to explain and hard to do well. Almost every team that tries it ends up with 80% of the backlog marked Must, which is the same as not prioritising at all. This guide shows how to run MoSCoW so the priorities survive contact with a deadline: how to define Must, how to run the workshop, how to check the balance, and how to use the result when time runs short. MoSCoW comes from DSDM; for the framework around it, read DSDM explained, and for the full project walkthrough see How to implement DSDM.

One scenario runs through every step. An events company needs its new ticketing site live for the on-sale date of its biggest festival, twelve weeks away. Marketing has already announced the date. Product, marketing, finance and customer service each have a list of things they consider essential.

Who this is for

• Product owners and business analysts who have to turn a long wish list into something that fits a date.
• Project managers running AgilePM or DSDM projects who want MoSCoW to do real work, not decorate a spreadsheet.
• Anyone who has sat through a prioritisation meeting where every stakeholder left with all their items marked Must.

Before you start

• A fixed timeframe. MoSCoW only means something relative to a deadline: a release, an increment or a timebox. “Must have, ever” is not a priority.
• One person with the final say. A sponsor or product owner who settles disagreements after the workshop. Without one, the loudest department wins.
• A rough list of requirements. Twenty to sixty lines is plenty. You don’t need detailed specifications to prioritise.

Step 1: Fix the timeframe you’re prioritising for

Write the timeframe at the top of the list before anyone sees it: “Priorities for the on-sale launch, 14 March.” Every priority is “for this timeframe”. This is what makes Won’t-have bearable: it means “won’t have this time”, not “never”.

In the scenario: the product owner titles the list “Ticketing site: on-sale launch”. The post-launch roadmap is a separate list, so stakeholders can see where deferred items go.

Step 2: Agree what Must means before you prioritise anything

Most MoSCoW failures start here. If you don’t agree a definition, everyone uses their own, and their own is “important to me”. Use a test that can be answered yes or no:

A requirement is a Must only if, without it, we would not launch at all: it would be illegal, unsafe, or the product would not work for its core purpose.

If there’s a workaround, even a painful manual one, it is a Should, not a Must.

In the scenario: the group agrees the test before looking at the list. That alone moves “seat selection” from Must to Should: general admission tickets meet the core purpose, and seat selection only applies to one venue area.

Step 3: Get a rough effort for every item

You can’t check the balance without effort estimates. They don’t need to be precise; days or T-shirt sizes converted to days are enough. Ask the delivery team, not the stakeholders, and do it before the workshop so the conversation includes cost.

In the scenario: the team estimates 28 items in an afternoon, in days. Total effort comes to 190 days against roughly 120 days of capacity before the on-sale date.

Step 4: Run the prioritisation workshop

Run it as a facilitated workshop with the people who own the requirements and the person with the final say. Use the agenda in the templates below. The facilitator’s job is to apply the Must test from Step 2 to every proposed Must, out loud.

Two rules keep the workshop honest:

1. Every Must needs a one-line reason that passes the test.
2. Nobody can add a Must without saying which existing Must it’s more important than, if the balance check fails.

In the scenario: marketing proposes the referral discount as a Must. The facilitator asks: “Without it, would we not launch?” The answer is no; it moves to Could. Payment processing, ticket delivery by email, and the accessibility requirements stay Must, with reasons written beside them.

Step 5: Check the balance by effort

Add up the effort in each category, counting only what you plan to deliver in the timeframe, which can’t be more than the team’s capacity. DSDM’s guidance is that Must-haves should be no more than about 60% of that planned effort, with the rest split between Should and Could (Could typically around 20%). The Shoulds and Coulds are your contingency: when estimates turn out wrong, they’re what you drop to protect the date and the Musts.

Measure against capacity, not against the whole wish list. A long list of Coulds that will never fit makes the Must share look small without giving you any contingency.

The number of items doesn’t matter. Ten small Musts and one huge Could tells you nothing; effort is what has to fit in the time.

In the scenario: after the first pass, Musts total 104 days. That looks like 55% of the 190-day list, but the team only has about 120 days, so Musts would be 87% of what can be delivered, leaving almost no contingency. The facilitator runs the Must test again on the biggest Musts. Seat-map accessibility moves into the general accessibility work, and two reporting items become Shoulds. Musts come down to 70 days, 58% of the 120-day capacity. The plan for the launch is Musts (70 days), Shoulds (30) and Coulds (20). The other 70 days of requests go on the Won’t list for this release.

Step 6: Write down the decisions and the Won’t list

Publish the prioritised list with the reasons, the owner of each item, and the Won’t list. The Won’t list is as important as the Must list: it’s the record of what stakeholders agreed not to get this time, and it stops the same argument restarting in week six.

In the scenario: the Won’t list includes the mobile app, multi-currency pricing and the loyalty scheme, each with a note on where it goes next. Finance signs off the list, because its multi-currency request is on it.

Step 7: Use the priorities when time runs short

MoSCoW earns its keep when something slips. Apply it in order:

1. Drop Could-haves.
2. Drop Should-haves, with the product owner’s agreement.
3. If a Must-have is at risk, escalate to the person with the final say the same day.

Prioritise again at a smaller scale for every sprint or timebox: each one gets its own Musts, Shoulds and Coulds taken from the release list, so there’s room to absorb problems inside each timebox too.

In the scenario: in week seven, the payment provider’s fraud checks take longer to integrate than estimated. The team drops two Coulds (the referral discount and an FAQ chatbot) and pushes one Should (gift tickets) to after launch. No Must is at risk, so it’s reported at the fortnightly review rather than as an escalation.

Step 8: Revisit at every increment boundary

Priorities change as the business learns. At each release or increment boundary, review the whole list: some Coulds become irrelevant, some Won’ts become next increment’s Musts. Keep the Must test the same so the meaning doesn’t drift.

In the scenario: after launch, the gift tickets Should and the deferred seat selection become Musts for the summer release, because the venue sells reserved seating from June.

Copy-paste templates

Prioritisation table with balance check

Priorities for: ________________________   Deadline: __________   Capacity (days): 90

| ID  | Requirement                     | MoSCoW | Effort (days) | Owner        | Reason (Musts must pass the test)          |
|-----|---------------------------------|--------|---------------|--------------|--------------------------------------------|
| T01 | Buy general admission tickets   | Must   | 20            | Product      | Core purpose of the site                   |
| T02 | Card and wallet payments        | Must   | 18            | Finance      | Can't sell tickets without it              |
| T03 | E-ticket delivery by email      | Must   | 8             | Ops          | Customers can't attend without a ticket    |
| T04 | Accessibility (WCAG 2.2 AA)     | Must   | 12            | Product      | Legal and policy requirement               |
| T05 | Seat selection                  | Should | 15            | Ops          | One area only; GA is a workaround          |
| T06 | Gift tickets                    | Should | 6             | Marketing    | Valued, not required to launch             |
| T07 | Referral discount               | Could  | 5             | Marketing    | Launch works without it                    |
| T08 | Multi-currency pricing          | Won't  | -             | Finance      | Not this time; next release                |

Balance check (by effort, not by count)
  Planned: 84 days   (Must + Should + Could, excluding Won't)   capacity: 90 days -> fits
  Must:    58 days   (58 / 84 = 69%)   target: <= 60%  -> rebalance before planning
  Should:  21 days   (25%)
  Could:    5 days   (6%)
  If planned is more than capacity, move items to Won't first, then check the Must share.

Stakeholder workshop agenda (2 hours)

1. Purpose and timeframe (5 min)
   - What we're prioritising for, and the fixed date
2. Agree the Must test (10 min)
   - "Without it, would we not launch: illegal, unsafe, or unusable for its core purpose?"
   - Any workaround = Should
3. Walk the list, item by item (60 min)
   - Owner proposes a priority
   - Facilitator applies the Must test to every proposed Must, out loud
   - Write the reason beside each Must
4. Balance check (15 min)
   - Total effort per category, for what fits in capacity; Must <= ~60%?
   - If over: each owner names which of their Musts could drop
5. Won't list (15 min)
   - Read it out; note where each item goes next
6. Decisions and owner (15 min)
   - Person with the final say confirms the list
   - Date of the next review

The Must test (print it, put it on the wall)

Is it a MUST for this timeframe?
  [ ] Without it, we would not launch at all
  [ ] Because it would be illegal, unsafe, or the product wouldn't do its core job
  [ ] And there is no workaround, even a manual one
All three ticked -> Must.   Otherwise -> Should or Could.

Common mistakes

Everything is a Must. The workshop ends with 80% of effort in Must. Fix: agree the Must test before looking at the list, and run the balance check by effort before anyone leaves the room.

Counting items instead of effort. “Only 12 of our 40 items are Musts” sounds fine until the 12 are the biggest. Fix: always total by estimated effort.

Won’t means never. Stakeholders fight every Won’t because they think it’s a permanent rejection. Fix: title the list with its timeframe and put a “where it goes next” note on each Won’t.

Ranking inside Must. “Must 1, Must 2, Must 3” means the team has given up on the categories. Fix: if you need to rank, the lower ones aren’t Musts.

Prioritising once. The list is set at the start and never revisited. Fix: give every sprint or timebox its own MoSCoW and review the whole list at each increment boundary.

No final say. Disagreements leave the workshop unresolved and get decided by escalation in week six. Fix: name the person with the final say before the workshop and have them in the room.

You’re done when

• The list has a timeframe and a fixed date at the top
• The Must test was agreed before prioritising started
• Every item has a rough effort estimate from the delivery team
• Every Must has a one-line reason that passes the test
• Musts are at or under about 60% of the effort that fits in the timeframe
• The Won’t list is published with a “where it goes next” note
• The person with the final say has confirmed the list
• Each sprint or timebox will get its own MoSCoW from this list