Prioritisation

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

MoSCoWA DSDM technique that sorts requirements for a timebox into Must, Should, Could and Won't have (this time). comes from the DSDM agile method. It sorts requirements into four groups for a given release or timeboxA fixed period or release, such as "first release, end of June", that priorities are set against.:

The lower-case o's are just there to make the word pronounceable.

Two rules make MoSCoW work:

1. 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 contingencySpare capacity that the Should and Could items provide, because they can be dropped if work runs late.. If everything is a Must, nothing is.
2. 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):

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 WSJFWeighted shortest job first, a SAFe scoring method that formalises value against size. (weighted shortest job first, used in SAFe) formalise this.

Running a prioritisation session

1. Share the list, goals and sizes before the meeting.
2. Agree the timebox: "first release, end of June".
3. Start by agreeing the Musts using the "do we cancel the launch?" test.
4. Sort the rest, discussing only the ones people disagree on.
5. Check the Must total against capacity. Too many? Push back and re-test each one.
6. 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.