MoSCoW Prioritisation: Must, Should, Could and Won't

MoSCoW is a way to sort the work for a release into four groups: must have, should have, could have and won't have this time. It helps a team agree what's truly essential when the date or budget can't move.

The name comes from the first letters of each group, with two o's added so it's easy to say. It's simple to explain to anyone, which is a big part of why it has lasted.

The Origins of MoSCoW

MoSCoW was created by Dai Clegg in the 1990s and became part of DSDM, the Dynamic Systems Development Method. DSDM fixes time and cost and lets scope flex. MoSCoW is the tool that decides which scope flexes first.

What Each Category Means

• Must have. Without it, the release is unsafe, illegal, unusable or pointless. If you'd delay the release rather than ship without it, it's a must.
• Should have. Important and valuable. You'd be disappointed to leave it out, but you could release without it if you must.
• Could have. Genuinely useful, but you're happy for it to wait.
• Won't have this time. Not in this release. It may come back later. It hasn't been rejected.

When to Choose MoSCoW

Choose MoSCoW when a release or deadline is fixed and you must agree what's truly essential. Regulatory changes, events, seasonal launches and contract dates are good examples.

It's less helpful for ranking a long, open-ended backlog. For that, a scoring method such as RICE or WSJF gives you a clearer order.

How to Use MoSCoW, Step by Step

1. Name the release and its date. MoSCoW only makes sense against a specific time frame.
2. Agree the definitions before sorting. Write down what "must" means for this release, in a sentence.
3. Agree who makes the final call. Decide how disagreements will be settled before they happen.
4. Estimate effort for each item. Rough sizes are enough.
5. Sort every item. Challenge each must with one question: would we really delay the release for this?
6. Check the balance. Musts should be well under two thirds of the total effort.
7. Revisit as you learn. Priorities are allowed to change. Record when they do and why.

A Worked Example

A small theatre is launching online ticket sales before its winter season opens. The date is fixed. Here's how the team sorted the work.

Item	Category	Effort (weeks)
Choose seats and pay by card	Must	4
Email ticket confirmation	Must	1
Accessibility requirements at booking	Must	1
Gift vouchers	Should	2
Member discounts applied automatically	Should	1
Interval drinks pre-order	Could	2
Seat view photos	Won't this time	2

Musts add up to six weeks out of thirteen, which is under half. That leaves room to absorb surprises. If the card payment work runs late, the team can drop drinks pre-order first, then gift vouchers, without moving the opening night.

Seat view photos are a won't this time. Everyone liked them. They're simply not needed for this release.

Making the Must Conversation Easier

The hardest part of MoSCoW is agreeing what's truly a must. People naturally want their own work protected. A few habits make this much easier.

First, use a test question rather than a debate. "Would we delay the release rather than ship without this?" is clear and fair. If the honest answer is no, it isn't a must.

Second, look at musts through the customer's eyes. Ask what a customer would need to complete their task safely and legally. Internal wishes rarely pass that test.

Third, make the trade-offs visible. Show the effort in each group as a simple bar. When people can see musts eating most of the plan, they become far more willing to move things down.

Fourth, agree how you'll handle change. New musts will appear. When one does, something else must move down to make room. Saying this upfront saves a lot of tension later.

Finally, remember that a won't this time is a kindness. It tells people their idea was heard and has a place to wait. That's much easier to accept than silence.

Common Mistakes

• Too many musts. When everything is a must, nothing is. A common rule of thumb is to keep musts to around 60% of the effort.
• Reading "won't" as "never". People get upset when their idea lands there. Keep a separate rejected list for ideas you've truly dropped.
• Forgetting the time frame. A could have for this release might be a must for the next one.
• Sorting without effort. You can't tell if the plan is safe unless you know how big each group is.
• Treating shoulds as secret musts. If you'd never ship without it, call it a must and make the trade-off visible.

How MoSCoW Compares with Other Tools

MoSCoW and RICE answer different questions. MoSCoW asks what must be in this release. RICE asks which idea gives most value for the effort.

MoSCoW and the Kano model work well together. Kano basics often become musts. Delighters are often coulds that make a release memorable.

MoSCoW and Cost of Delay also pair nicely. Cost of Delay helps you order the shoulds and coulds once the musts are agreed.

In my experience, the most valuable part of MoSCoW is the conversation about musts. When a team agrees honestly what it can't live without, planning becomes much calmer.

The Product Field Kit includes a fillable MoSCoW worksheet and a calculator that shows the share of effort in each category and warns you when musts get too heavy.

Questions People Ask

← More Field Notes