Prioritise requirements with MoSCoW, back the choices with value and cost, and get stakeholders to agree.
Why it matters
Every project has more requests than time and money. If nothing is prioritised, the team builds whatever is loudest or easiest, and the most valuable work is still unfinished at the deadline. Prioritisation is a decision the business makes, but analysts set it up: they make the options, values and costs visible so the decision is informed and agreed.
MoSCoW
MoSCoW comes from the DSDM agile method. It sorts requirements into four groups for a given release or timebox:
| Group | Meaning | Test question |
|---|---|---|
| Must have | Without it the release is useless, unsafe or illegal | "If this is missing, do we cancel the launch?" |
| Should have | Important and valuable, but there is a workaround | "Is there a painful but possible way round it?" |
| Could have | Nice to have; small impact if left out | "Would anyone complain much if it slipped?" |
| Won't have (this time) | Agreed out of scope for this release | "Can we say no now and revisit later?" |
The lower-case o's are just there to make the word pronounceable.
Two rules make MoSCoW work:
- Must haves are a minority. DSDM guidance suggests no more than about 60% of the effort goes on Must haves, leaving the Shoulds and Coulds as contingency. If everything is a Must, nothing is.
- Won't is a real category. Writing "Won't have this time" manages expectations and stops scope creeping back in.
Worked example: Riverside Library, first release
The requirements list after elicitation, with rough sizes from the team (S, M, L):
| ID | Requirement | Size | MoSCoW | Why |
|---|---|---|---|---|
| FR-01 | Member sees room availability by day | M | Must | Core of the problem |
| FR-02 | Member books a free room online | M | Must | Core of the problem |
| FR-03 | System refuses overlapping bookings | S | Must | Double bookings are the top complaint |
| FR-04 | Confirmation email on booking | S | Should | Phone confirmation still possible |
| FR-05 | Member cancels own booking | S | Should | Librarians can cancel by phone meanwhile |
| FR-06 | Recurring weekly bookings | L | Could | Few groups need it; book week by week |
| FR-07 | Online payment for room hire | L | Won't (this time) | Rooms are free today; revisit next year |
| NFR-02 | Keyboard and screen-reader accessible | M | Must | Legal duty and library policy |
The Musts are about half the effort. If the build runs late, FR-06 drops first, then the Shoulds, and the release still solves the main problem.
Backing choices with evidence
MoSCoW answers "how important", but stakeholders still argue. Help them with:
- Value: link each requirement to a goal ("cuts staff phone time"). If it links to no goal, ask why it is there.
- Cost or size: a small Should may be worth doing before a large Could.
- Risk and dependencies: something that unblocks other work, or tests a risky assumption, may go earlier.
- Simple scoring where there is disagreement: rate value and cost 1 to 5 and look at value divided by cost. Frameworks such as RICE (reach, impact, confidence, effort) and WSJF (weighted shortest job first, used in SAFe) formalise this.
Running a prioritisation session
- Share the list, goals and sizes before the meeting.
- Agree the timebox: "first release, end of June".
- Start by agreeing the Musts using the "do we cancel the launch?" test.
- Sort the rest, discussing only the ones people disagree on.
- Check the Must total against capacity. Too many? Push back and re-test each one.
- Record decisions and reasons, and who made them.
The sponsor or product owner decides; the analyst facilitates and records. Stakeholders accept a "no" far more easily when they saw the trade-off being made.
Common mistakes
- Everything is a Must. Ask "what happens on launch day if this is missing?"
- Prioritising without sizes, so a huge Could quietly eats the Shoulds.
- No timebox. "Should have" only means something relative to a release.
- Never revisiting. Priorities change as you learn; review them every release or sprint.
Quick recap
- MoSCoW sorts work for a timebox into Must, Should, Could and Won't (this time).
- Keep Musts to a minority of effort so the rest acts as contingency.
- Back choices with value, size, risk and dependencies; the sponsor decides.
- Record decisions and revisit them.
Try it
Open the Do tab and run a MoSCoW session on your own requirements list.