Meeting canvases · Prioritise
MoSCoW prioritization: agree what is in, what is out, and why
MoSCoW prioritization, also called the MoSCoW method, is how a team agrees scope by putting each requirement in one of four groups: Must have, Should have, Could have and Won’t have this time. The Musts are the minimum the release cannot do without, kept to about 60% of the effort so the rest leaves room for surprises.
Troopa sorts the list into the four groups during your call on Teams, Zoom or Google Meet, as the room argues each item. Say “Hi Troopa, let’s do MoSCoW for the card launch” and the board fills in, while the transcript keeps the reason each item landed where it did.
14 days free, no card. Then $15 per seat, per month. Cancel any time. Last checked against the product on 21 October 2026.
Why MoSCoW sessions stall
- Everything is a Must, because everyone marks their own items before anyone has talked.
- There is no agreed way to settle a disagreement, so the loudest person wins.
- Stakeholders fight for Must because they believe anything less will never be built.
- The line between a Should and a Could turns into a long and heated argument.
- The Won’t list is deleted rather than kept, so the same items come back next week.
- The groups are set at the kick-off and never looked at again.
How to run MoSCoW prioritization with Troopa
Step 1: Open the board
Say “Hi Troopa, let’s do MoSCoW for the card launch”. Troopa offers it as a meeting called a prioritisation starts, and in a planning meeting when the room starts arguing about what is in.
Step 2: Argue it out loud
Each item goes under Must have, Should have, Could have or Won’t have this time as the room places it. Say “that’s a Could” and it moves.
Step 3: Test every Must
For each Must, ask whether you would stop the launch without it. The ones that fail move down a group, on the card or by saying so.
Step 4: Keep the Won’ts
Won’t have this time is a column, not a bin: those items stay on the board with the rest, so nobody has to argue for them again next week.
Step 5: Share the scope
Present the board to agree it, then download it as Excel or CSV for the plan, or as a PDF for the people who were not there.
A worked example: scoping a card launch
A payments start-up is agreeing the scope of its first card, with a launch date set by its partner bank. Zoe runs the session on Teams with Troopa open.
- Zoe“Hi Troopa, let’s do MoSCoW for the card launch.”
- Arun“Strong customer authentication is a must. We can’t launch without it.”
- Bea“Apple Pay should be in, but people can use the card without it.”
- Arun“Spending insights could go in if there’s time.”
- Zoe“Multi-currency isn’t happening this time. Let’s say so, so it stops coming up.”
- Bea“Is freezing the card in the app really a must?”
- Arun“Would we stop the launch without it? Yes. It’s how people stop fraud on a lost card.”
MoSCoW prioritization across industries
Fintech and payments
A regulated launch with a date the bank or the regulator set: anything the launch would be illegal or unsafe without is a Must by definition, and the rest is sorted around it.
Public sector
A council service in beta, where accessibility and the law are Musts and the nice-to-haves wait. GOV.UK’s Service Manual suggests MoSCoW when a team needs to build consensus.
Agencies and consultancies
A fixed-fee website or campaign: MoSCoW at the kick-off goes into the statement of work, and the Won’t list is signed off too, so “small extras” have somewhere to go that is not the budget.
Healthcare operations
Scoping a patient portal’s first release: data protection, accessibility and booking and cancelling are Musts, text reminders a Should, self-service rescheduling a Could. Release scope only, nothing clinical.
Manufacturing
The go-live scope of a new business system: order to cash and the statutory reports are Musts, the extra dashboards are Coulds, and the go-live date holds.
HR and people teams
A payroll or HR system migration, where paying people correctly and on time is the only Must, and self-service extras are argued about once that is safe.
A MoSCoW template with the definitions built in
Agree the definitions and how disagreements will be settled before you sort a single item. Then check the share of effort in each group at the end, not just the number of items.
Release: [name] Fixed date: [date] Decides in a tie: [name] Must have: we would stop the launch without it; there is no workaround Should have: important and painful to leave out, but a workaround exists Could have: wanted, and the first to go if the date is at risk Won’t have this time: agreed to be out of this release, kept on the list ID | Item | Group | Why, in one line | Effort | Depends on | Revisit when 1 | [..] | Must | [..] | [..] | [..] | 2 | [..] | Won’t | [..] | [..] | | [next release] Check: Must effort no more than about 60% of the total; Could about 20% Won’t have this time: [items], so they are not argued for again
Questions that sort a Must from a Should
- What happens if this is not delivered? Would we cancel, or stop the launch the night before?
- Is there any workaround at all, even a slow, manual one? If so, it is a Should.
- Can this Must be split, and is every part of it equally essential?
- Does this Must depend on anything that is not itself a Must?
- Start with everything as a Won’t and make each item argue its way up, if everything keeps landing in Must.
- Look at the groups again at the end of every timebox: priorities change as you learn.
Questions about MoSCoW prioritization
What does MoSCoW stand for?
Must have, Should have, Could have and Won’t have this time. The two lower-case o’s are only there to make the word pronounceable; the method has nothing to do with the city.
What does the W in MoSCoW mean?
Won’t have this time: the items agreed to be out of this release or timebox. Some teams read it as wish or would, but “this time” is the point, since the item is kept on the list for later rather than thrown away.
What is the 60% rule in MoSCoW?
The Agile Business Consortium advises keeping Must have work to no more than about 60% of the effort, with Could haves around 20%. The Coulds are the contingency: they are what gets dropped if the work turns out bigger than planned, so the Musts are still delivered on time.Agile Business Consortium, What is MoSCoW prioritization? →
Who created the MoSCoW method?
Dai Clegg of Oracle UK devised it for rapid application development and published it with Richard Barker in a 1994 book. The DSDM Consortium, now the Agile Business Consortium, then adopted it and wrote the rules most teams follow today.Bittner and Spence, Use Case Modeling (Addison-Wesley, 2002), chapter 3, note 10 →
Is MoSCoW an agile technique?
Yes. It came from rapid application development and is part of DSDM, one of the earliest agile frameworks. Scrum teams use it to agree what a release or sprint must contain, and GOV.UK’s Service Manual suggests it for building consensus about priorities.GOV.UK Service Manual, Deciding on priorities →
What are the disadvantages of MoSCoW prioritisation?
It does not rank items within a group, so five Shoulds still need ordering; it invites everyone to call their item a Must; and the Should and Could line is a judgement. Agreed definitions, a tie-break and a cap on Must effort deal with most of it.
Sources
- Agile Business Consortium, What is MoSCoW prioritization?
- Bittner and Spence, Use Case Modeling (Addison-Wesley, 2002), chapter 3, note 10
- GOV.UK Service Manual, Deciding on priorities
Read on 15 October 2026, by the people who make Troopa.
DSDM® is a registered trade mark of Dynamic Systems Development Method Limited. Troopa is not affiliated with the Agile Business Consortium.
Try it in your next meeting
Install Troopa on your Mac, Windows PC or Ubuntu computer, join your call on Teams, Zoom or Google Meet as you always do, and ask: “Hi Troopa, let’s do MoSCoW for the card launch.”
14 days free, no card. Then $15 per seat, per month. Cancel any time.