MoSCoW is a prioritisation method that splits the requirements of a release into four categories: Must (without it the release makes no sense), Should (important, but the release survives without it), Could (desirable, goes in if capacity allows) and Won't (left out this time, by recorded decision). The rule of thumb is to keep Must below 60% of the effort, so there is room when estimates prove wrong.
How to use
- Say what this prioritisation decides (a release, a quarter) and, if you know it, the team capacity.
- Write one requirement per row, choose its category and estimate effort in the same unit for all.
- Justify each Must: what happens if it is left out.
- Read the board and the warnings: Must above 60%, nothing in Won't, Must without justification or capacity exceeded.
- Export the board as PNG, PDF, CSV or Markdown and use it in the conversation with stakeholders.
What each field asks for
| Field | What to enter |
|---|---|
| Release or period (optional) | What this prioritisation decides. |
| Capacity (optional) | How much the team can deliver in the period, in the same unit as effort. |
| Requirement | E.g. upfront payment |
| Category | |
| Effort | Points, days or another unit, the same for all |
| Justification | Required for Must |
Example
A team prioritises version 2.0 of a salon booking app, with a capacity of 40 working days. Three requirements are Must and add up to 17 (42.5% of capacity, below the 60% limit). Should adds up to 9 and Could to 11: everything fits in the 40. The tablet app for the salon goes into Won't, justified by validating demand first. The tool warns that customer cancellation is a Must without justification.
When to use
- When closing the scope of a release or an MVP with a fixed deadline.
- When every request arrives as urgent and you need to state, in writing, what waits.
- To negotiate scope with stakeholders by showing how much effort each category takes.
- After a Kano or RICE exercise, to turn the order into a release decision.
Frequently asked questions
What does each letter in MoSCoW mean?
Must have, Should have, Could have and Won't have this time. The letter "o" only makes the acronym pronounceable. The method came from fixed-deadline development projects in the 1990s.
Why limit Must to 60% of the effort?
Estimates go wrong. If almost everything is a Must, any delay puts the whole release at risk. With Must at up to 60%, Should and Could become a buffer: when something slips, a Could comes out and the essentials still stand.
How do I know whether something is truly a Must?
Ask what happens if it is left out. If the answer is "the release is useless", "we break the law" or "we breach the contract", it is a Must. If it is "customers are less happy" or "there is a manual workaround", it is a Should.
Why record the Won't items?
Saying what is left out matters as much as saying what goes in. Recording Won't items, with the reason, stops the same request coming back at every meeting and shows it was considered, not forgotten.
How is MoSCoW different from RICE?
RICE ranks items by a score; MoSCoW decides what goes into a specific release. Many teams use RICE or the impact effort matrix to rank and MoSCoW to close the scope of the release.
Who decides the category?
The person accountable for the product decides, after hearing from the people who build and the people who use it. The category needs an explicit justification, especially a Must: that is what lets the decision be discussed without turning into a power struggle.