Glossary
What is MoSCoW prioritisation?
A prioritisation technique that sorts requirements for a fixed timebox into four categories — Must have, Should have, Could have and Won't have this time — so that everyone agrees in advance what is dropped first if time runs short.
The categories only mean something against a fixed deadline and fixed capacity. A Must is whatever the delivery would be pointless, unsafe or unlawful without on that date — not whatever matters most to the person asking. Take away the fixed box and the four labels are just strength of feeling.
The four categories, and where they came from
MoSCoW prioritisation (prioritization, in US spelling) was devised by Dai Clegg at Oracle in the 1990s and became a core practice of DSDM, the agile delivery framework; the lower-case letters are only there to make the initials pronounceable. A Must have is something the delivery cannot go live without. A Should have is important but has a workaround, however painful. A Could have is wanted and costs little if left out. Won't have this time is agreed to be outside this timebox: not rejected for ever, and not coming now.
The test for a Must is a question: what happens if this is not delivered? If the honest answer is "we would find a way round it", it is a Should.
The 60 per cent guideline
DSDM's guidance is that Must haves should take no more than about 60 per cent of the effort in a timebox, with Could haves at around 20 per cent acting as the contingency. The arithmetic is the point: estimates are wrong, and the only way to guarantee the Musts on a fixed date is to carry work that can be dropped without a negotiation. A plan that is 90 per cent Musts has no contingency; it has moved the argument to the week before the deadline.
That makes MoSCoW a capacity technique as much as a prioritisation one. The categories cannot be assigned before the work is sized, because whether something can be a Must depends on how much of the box the other Musts already fill.
Why "Won't" is the valuable category
Three of the four categories describe things that will probably be attempted. Won't have this time is the only one that records a decision not to, and it is what holds scope still: when the excluded item is asked for again in week six, the answer already exists and has a date on it. A MoSCoW list with an empty Won't column has not prioritised anything; it has sorted a wish list.
The common failure is that everything becomes a Must. It happens whenever the label is negotiated by importance instead of tested against the deadline, and whenever stakeholders have learned that Should and Could are polite words for never. The cure is to deliver the Shoulds often enough that the category is believed, and to hold the 60 per cent line so that adding a Must means naming the one it displaces.
Related terms
- Commitment exception — A recorded justification required to commit to work that is not yet decision-ready, naming why it is early, what is still unknown, who accepts the risk, and what condition would change the decision.
- Delivery governance — The practice of deciding what to commit to — establishing value, ownership, capacity, dependencies and open questions before people, budget or a date are promised.
- Decision-ready demand — A demand that can responsibly be committed to: the problem stated apart from the proposed solution, an intended outcome, a named owner, a first capacity figure, the dependencies, and the open questions written down as unknowns.
This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.