Framework library · Decision making and problem solving
MoSCoW prioritisation
MoSCoW sorts the requirements for a release or project into four groups: must have, should have, could have and won't have this time. It is a tool for fixed deadlines. The must haves are the minimum without which the release is useless. The should and could haves are the contingency that gets dropped if the work runs late. It works only if the must haves are kept to a share of the effort the team is confident it can deliver.
Use it when
- A release or project has a fixed date, such as a regulatory deadline or a partner's launch, and scope must give way if the work runs late.
- Stakeholders each believe their requirement cannot be dropped, and you need a common language to settle it.
- You want to agree in advance what will be dropped first, rather than deciding under pressure in the last fortnight.
Avoid it when
- You need to rank a long backlog by value for effort. RICE scoring or a weighted decision matrix ranks; MoSCoW only sorts into four groups.
- The deadline can move. Without a fixed date the categories lose their meaning and everything drifts towards must have.
- You are choosing between strategies or investments rather than scoping a delivery. Use a weighted decision matrix.
How to run it
Fix the date and the boundary of the release
Name the release and its deadline. MoSCoW sorts within a fixed period of work.
Test every must have
Ask whether the release would be cancelled if this were missing. If there is a workaround, however painful, it is a should have.
Sort the rest
Should haves are important, but the release still works without them. Could haves are wanted but matter less. Won't have this time is agreed and recorded, not forgotten.
Estimate the effort for each
Person-days from the delivery team, for everything except the won't haves.
Check the share of effort
DSDM's guidance is to keep must haves at or below 60% of the effort, with around 20% in could haves as contingency. The workbench flags anything above 60%.
Agree the drop order
If the work runs late, could haves go first, then should haves. Agree this with the stakeholders before work starts.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Calling most things must haves. Above 60% of the effort, the release has almost no room to absorb an overrun.
- Treating won't have as never. It means not in this release; record it so it comes back for the next one.
- Sorting without effort estimates, so the share of must haves is unknown until it is too late.
- Letting whoever asked for a requirement decide its category. The business owner decides, with the delivery team's estimate in front of them.
Where it comes from
Developed by Dai Clegg of Oracle UK Consulting and published in Dai Clegg and Richard Barker, Case Method Fast-Track: A RAD Approach (Addison-Wesley, 1994). It became the prioritisation method of DSDM, whose handbook, now published by the Agile Business Consortium, advises keeping must haves to no more than 60% of the effort. Source.
Use it with
Further reading
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.