MoSCoW prioritization: how it works, with an example

MoSCoW prioritization sorts everything you might build into four groups: must have, should have, could have and won't have this time. A must have is something the release fails without, and if any workaround exists, the item belongs lower down. The Agile Business Consortium, which publishes the DSDM framework the method is part of, adds a limit: keep must haves to no more than about 60% of the effort, so there is something left to drop when an estimate slips.

Those two rules do most of the work. Without them, MoSCoW turns into high, medium and low with longer names, and most of the list ends up at the top.

Dai Clegg developed the method in 1994 for rapid application development, and it was used widely with the Dynamic Systems Development Method (DSDM) from 2002. The capitals are the four groups. The two lower-case o's stand for nothing and only make the word pronounceable.

This guide shows the result first and the argument second, since the finished board is easier to follow once you've seen it. The example is invented. We make Prompt Board, and our MoSCoW prioritization template carries the same nine features and headings as its sample, so you can open it beside this page.

The finished board

A made-up small software team is planning release 2.0 of its project-tracking tool. Two developers have four weeks, which is 40 working days between them. Two larger customers have signed on the condition that the release meets their security review. The day counts are invented too, as the team's estimates.

The totals add up to the capacity exactly: 24 days of must haves, 9 of should haves and 7 of could haves make 40. Must have sits at 60%, should have at 22.5% and could have at 17.5%.

How the board looked an hour earlier

The first sort went the way these meetings usually go. Sales wanted dark mode in Must have, because prospects ask about it in demos. Support wanted bulk edit there, because customers complain about changing records one at a time. Nobody objected, and Must have held five notes worth 33 of the 40 days, or 82.5%.

The product lead then read each note aloud and asked one question: if this is missing on release day, do we call the release off? The Agile Business Consortium words the test as what happens if the requirement isn't met. If the honest answer is to cancel, because there's no point delivering without it, the item is a must have.

Single sign-on. Both contracts name it. Without it the two customers can't go live, so the release has no purpose. It stays.

Audit log. It's on the security questionnaire both customers have to pass. It stays.

Data export. This one took longest. Support pointed out that they could send customers a CSV by hand, and the consortium's guidance says plainly that "if a workaround exists, then it is not a Must Have requirement". Then someone checked the contracts, which ask for export the customer can run without contacting support. A hand-sent file doesn't meet that, so export stays.

Dark mode. Sales still wanted it, but nobody would cancel the release over it. Should have.

Bulk edit. Leaving it out hurts, but people can change records one at a time as they do today. That is a workaround, even if it's a dull one. Should have.

Those two moves took Must have from 33 days to 24, which is the 60% in the table. Nothing was cut from the plan. Dark mode and bulk edit still fit, and the team now knows they aren't guaranteed.

Why the effort limit matters

It's easy to apply the 60% to the number of notes. The guidance applies it to effort, which is why the board above needs day counts. Three of nine notes look modest as a count, but those three take 60% of the time.

The limit exists because estimates go wrong. The guidance warns that must have effort above 60% introduces a risk of failure, and it allows more only when estimates are accurate, the approach is well understood, the team performs well and the environment is low risk. It suggests keeping around 20% as could haves, which are the first choice of what to drop.

Here's how that played out. In week three, single sign-on ran three days over, 13 instead of 10. The team dropped keyboard macros, estimated at three days. Nobody needed a meeting, because the board already said could haves go first. The remaining plan came to 27 days of must haves, 9 of should haves and 4 of custom themes, which is 40 again.

Had Must have stayed at 33 days, this overrun would still have fitted: dropping keyboard macros makes it 36 days plus 4 of custom themes, which is 40. What changes is the margin. Only 7 of the 40 days could be given up, against 16 on the real board, where the 9 days of should haves can go too. One more slip of this size would use up nearly all of it, with dark mode and bulk edit already promised to people.

What the Won't group is for

Offline mode and the desktop app had people behind them too. Writing them under "Won't have now" records a decision: the team has agreed not to deliver them in this release. When someone asks what happened to their feature, the board answers before a meeting is needed.

The word "now" matters. Wikipedia's article lists ambiguity as a known criticism of MoSCoW, because "won't have" can read as this release or as never. The consortium's full name for the group is "Won't Have this time". Our template's heading says "Won't have now" for the same reason. Bring those notes back to the table when you plan the next release, or those requests get forgotten.

Questions for sorting your own list

Put each item through these in order, and stop at the first yes.

1. If this is missing on release day, do we cancel the release? Must have.
2. Would leaving it out hurt, while the release still works with a workaround? Should have. The consortium's wording is "important but not vital".
3. Do people want it, with less harm if it's missing? Could have.
4. Everything else that has been asked for goes in Won't have now.

Then add up the days. If Must have comes out above 60%, go through it again, and look for the items that have a workaround nobody has mentioned yet. Invite whoever can say what's in the contract or the regulation, because "must" questions often come down to one sentence in a document someone has to go and find.

Book an hour for ten to twenty items. Estimates can be rough, but you need them before the meeting ends or the effort check can't happen.

Where MoSCoW falls short

The method has limits, and Wikipedia's article names some of them. It doesn't rank items inside a group, so it can't tell you which should have to build first. It also gives little guidance on why something is a must and not a should, which is why the workaround test matters so much. And it can pull attention towards new features and away from work such as refactoring.

It also needs a fixed scope to work on. If you're choosing between ideas and haven't set a release yet, an impact effort matrix is the better first step. If you can't yet say what a user could do after each release, a user story map shows that, and MoSCoW can then settle what's left inside the first slice. When the releases have dates, they go on a product roadmap.

Frequently asked questions

What does MoSCoW stand for?

Must have, Should have, Could have and Won't have this time. The two o's are only there to make it pronounceable.

What percentage should be must have?

The Agile Business Consortium's guidance is typically no more than 60% of the effort, with around 20% as could haves. It's measured in effort, so count days or points and not the number of items.

What is the difference between should have and could have?

The guidance calls a should have "important but not vital", and says it may be painful to leave out while the solution stays viable. A could have is "wanted or desirable but less important", with less impact if it's left out. If you have to drop something, could haves go first.

Can a must have change between releases?

Yes. The guidance describes three levels: the project, the increment and the timebox. Its example is an archive facility, which is a must have before the project ends and can still be a should have or a could have for the first increment.

Who created the MoSCoW method?

Dai Clegg developed it in 1994 for rapid application development. It became widely used through DSDM from 2002.

Sort your own release

Pick the release with the fixed date and list everything anyone has asked for in it. Then open the MoSCoW prioritization template, replace the sample notes, and ask the cancel question out loud for every note someone wants in Must have. Share the board link afterwards, so the Won't have now column reaches the people whose features are in it.