The MoSCoW Method for Prioritizing Requirements

Everyone can recite Must, Should, Could, Won't. Almost no team can use them, because in practice every requirement climbs to Must and the method quietly stops sorting anything. That isn't a discipline problem. It's a definition problem: Must is not a level of importance, it's a claim about a failing case — and a claim nobody knows how to falsify will always be made.

A failed MoSCoW session does not look like failure. Sixty-three candidate requirements go out to eight stakeholders before a release planning workshop, everyone labels each one, and the votes come back with forty-one marked Must.

Nobody misunderstood the definitions — they were on the slide. Nobody was gaming, either, or at least not most of them. Each person read each line, asked themselves is this important, and answered honestly. The result was a Must list consuming roughly 140% of the team's estimated capacity, which means the method produced nothing at all. The sorting will now happen in week nine, under deadline pressure, by whoever is loudest.

Why every requirement climbs to Must

The usual response is "be more disciplined about Musts," which restates the problem rather than solving it. The escalation is structural, and two things drive it.

The labels are being used to express importance, and importance has no ceiling. Everything that survived onto a requirements list is already important — nobody proposed the unimportant ones. Importance is a comparative judgment, and MoSCoW doesn't ask for a comparison; it asks each item, in isolation, "which bucket?" A question asked in isolation cannot produce a sorted set.

And in most organizations, losing the Must label means losing the item. A stakeholder who accepts "Should" has watched Should items sit untouched for three releases and then quietly vanish. So the label isn't a priority, it's a claim on future capacity, and the rational move is to hold Must and never let go. That isn't bad faith — it's people correctly inferring that this is a one-shot game.

Both are fixable, but only by changing what the labels mean. The definitions on the slide describe feelings. They need to describe observable conditions.

What each label actually claims

Start from the original definition rather than the popular one. In DSDM — the framework MoSCoW comes from — Must is glossed as the Minimum Usable SubseT (Agile Business Consortium). That's not a property of a requirement. It's a property of a set: the smallest collection of things that together produce something a real person can use. An item is a Must only in the sense that removing it breaks the usability of the whole subset.

Which reframes the question. "Is this important?" has no defensible answer. "If this is missing on launch day, do we launch?" has exactly one — yes or no — said out loud in front of the people who will live with it. That's the falsification test, and with it all four labels become claims you can check:

Label	The claim it makes	How you falsify it	What being wrong costs you
Must	"If this is absent on launch day, we do not launch at all."	Ask what the affected person does on day one without it. If a tolerable path exists and survives the timebox at real volume, the claim is false.	A false Must eats the capacity a real Must needed. A missed Must ships something nobody can use.
Should	"Its absence hurts, and there's a path we can live with this timebox."	Say the path out loud and name who walks it. If nobody can describe the workaround in a sentence, it was a Must in disguise.	The workaround proves unworkable in week two and you take an emergency scope change under pressure.
Could	"We want it, and dropping it costs nothing structural this time."	Check whether anything else in the release depends on it. A Could with dependents is mislabeled.	You spend the contingency early, then have none when a Must runs long.
Won't	"Not this timebox — a scoping decision with a review date, not a rejection."	Confirm it has a named re-entry point. A Won't with no date is a cancellation wearing a friendlier label.	Stakeholders learn Won't means never, and next cycle refuse anything below Must — the inflation you just fixed returns.

Run this on your current release: next to each line on your Must list, write the one-sentence answer to "what does the affected person do on day one if this is absent?" Any line where you can write that sentence is not yet a Must. The count is the honest size of your prioritization problem.

One fork, walked

Illustrative composite drawn from patterns common in field-service and work-order modernization projects. The figures are composite, not measured.

A regional utilities contractor — call the release Brackwell R1 — was replacing paper work orders with a handheld app for a pilot depot of forty technicians. The date sat fourteen weeks out and could not move: the legacy ruggedized handhelds were leaving vendor support, after which a failed unit could not be re-provisioned. Sixty-three requirements, forty-one initial Musts.

The disputed item was a supervisor dashboard showing live job status across the depot. The operations director had marked it Must and was not moving. Asked directly — if the dashboard is missing on 3 November, do we launch? — she said no. Which settles nothing, because that question can be answered from conviction.

The follow-up moved the room: "What does the depot supervisor do on the morning of 4 November if it isn't there?"

A pause, then a completely ordinary answer: what she does today. A 7:30 phone round of the eight crew leads, about twelve minutes. It has worked for eleven years.

That is fatal to a Must claim, for a reason worth saying plainly: a Must is defined by the absence of a tolerable path, not by the presence of pain. Missing the dashboard would be worse; it would not stop the release from being a release. It became a Should with the condition in the record — revisit at increment 2, and the phone round stays in the depot runbook for R1 so nobody is surprised on the Monday.

Now the instructive contrast. Signature capture on the completed work order got the identical question and also had a workaround: paper signature, scan at end of shift, re-key into billing. A path exists, so by the crude version of the test it should have gone too.

It stayed a Must, and here the test gets its second half. Forty technicians at roughly nine jobs a day is about 360 forms a day to scan and re-key — and eliminating that re-key was the entire business case for R1. The workaround existed, but running it for the length of the timebox meant the release delivered nothing it was funded to deliver. So: does a path exist, and does that path survive the timebox at real volume? Both, or the claim doesn't hold.

The dashboard failed the first half; signature capture passed both. Same question, opposite outcomes, and the room could see why — which is what made the demotion survivable rather than a defeat.

The intake question that converts a claim into evidence

Notice what did the work. Not "is this important" — that produced forty-one Musts. Not even "would we launch without it," which invites a conviction. The move was to ask for a behavior on a specific date by a specific person. In the form that travels:

For each candidate Must: who cannot do their job on day one without this, what do they do instead, and does that alternative hold for the full length of the timebox at production volume?

Who attaches a name, so the claim gets checked with that person rather than asserted about them. What do they do instead converts an opinion into a description of a workflow — a factual claim someone can contradict. Does it hold at production volume is what stops the test demoting everything; it separated signature capture from the dashboard, and it usually requires a number somebody has to go and find.

That's discovery work, not prioritization work, and it belongs upstream of the session. Sending it out with the candidate list changes what comes back: stakeholders arrive having already found their own workarounds, which is a far less adversarial way to lose an argument. Getting a real workflow out of someone rather than a stated preference is its own craft — Requirements Elicitation Techniques That Work covers it, and observation in particular surfaces the manual path people have stopped noticing they use.

Run this on your current release: take the three Musts you're least sure about and write, for each, the person's name and the sentence describing what they do without it. If you have to guess at the sentence, you don't have a Must — you have an untested claim, and a fifteen-minute conversation resolves it.

Must needs a denominator

The failing-case test tells you whether an individual claim is honest. It doesn't tell you whether the resulting set fits.

DSDM's working guidance is that Must should be no more than around 60% of the effort in the timebox, with roughly 20% held as Could-have contingency (Agile Business Consortium). Treat that as a practitioner convention from the framework, not a measured research finding — but understand what it's for. It isn't a budget for ambition; it's the assumption that some estimates are wrong and that the Could items exist to be sacrificed when they are. A release with 95% of capacity in Must has no contingency, so the first miss becomes a missed date or an emergency scope negotiation you have no framework for.

The cap is also what turns the method into a forcing function rather than a labeling exercise. Without it, "everything is a Must" is merely inaccurate. With it, it's an arithmetic contradiction the room has to resolve while everyone is still in it.

On Brackwell, re-running the failing-case test took the Must list from 41 items to 22 — still about 71% of estimated capacity. Over. And the response to being over is not another round of arguing about labels:

Move	What it does	What it costs	When it's the right one
Split the requirement	Carves the thin usable core out of a fat Must and demotes the rest	Analysis time now; two backlog items to track	Almost always try this first — most Musts contain a Should
Narrow the user scope	Fewer users or scenarios this release, same feature set	A second rollout, and a migration path to maintain	The Must list is genuinely minimal but the population is broad
Move the date	Buys capacity directly	Usually unavailable, and it's the move that costs credibility	The date was a preference, not a constraint — check honestly which
Add capacity	More people or money against the same timebox	Ramp-up cost, and it rarely helps inside a short timebox	Early in a long timebox, with work that genuinely parallelizes

Brackwell used the first. Role-based permissions had been one Must; it split into technicians see only their own depot's jobs (a Must — the data exposure was contractual) and a configurable permission matrix in the admin UI (a Should — for R1, permission changes went through a ticket to the platform team, roughly two a week). That split, repeated across four requirements, brought Must to 58% of capacity.

Run this on your current release: total the estimate on your Must list and divide by the capacity of the timebox. Above roughly 0.6 and you have not finished prioritizing — and now you know which four moves are available instead of one more argument.

"Won't" means this timebox, and that's the whole trick

The most under-used label is the one that makes the other three politically possible.

In DSDM the category is Won't have this time, and the qualifier is load-bearing (Agile Business Consortium). Read without it, Won't is a rejection — and a stakeholder who hears rejection will fight to the last for Must, which is exactly the inflation the method was meant to prevent. Read with it, Won't is a scoping statement with a date attached, and it lets someone lose an argument without losing the item.

That only holds if the promise is real, which makes Won't an artifact rather than a verbal concession: a list, visible to the same stakeholders, each entry carrying its reconsideration date and who owns bringing it back. Brackwell kept a "Not in R1" register with nineteen entries and a standing slot at increment planning. Two came back as Musts for R2; three were dropped by the people who had fought hardest for them — the outcome that tells you the register worked. Given time and no threat of permanent loss, stakeholders discard their own requirements.

The register does a second job during execution. Must-creep — items promoted after the session, when there's no capacity left and no ceremony — is how a prioritized release quietly becomes an unprioritized one. The register plus one rule, promoting anything into Must requires naming what leaves, turns creep into a visible trade; Managing Requirements Changes Mid-Sprint covers the change-control side.

Run this on your current release: find your Won't list. If it isn't a durable artifact with review dates, your last session produced agreement rather than decisions — and the items you thought were settled are still live in the heads of the people who lost them.

Where MoSCoW is the wrong tool

MoSCoW is a binary ship gate under a fixed timebox. Everything above depends on both halves. Remove either and the method degrades into vocabulary.

No timebox, no denominator. A team on continuous flow — work pulled as capacity frees, shipped when ready — has nothing to be a Minimum Usable SubseT of. There's no launch day, so "would we launch without it" has no referent and the four labels collapse into synonyms for high/medium/low. Use a single ordered queue ranked by cost of delay or a WSJF-style weighting; what you need there is sequence, which MoSCoW deliberately doesn't provide.

When the real question is relative value, not shipability. MoSCoW has four levels of resolution and one is "not doing this." If every candidate is clearly optional and the question is which twelve of thirty return most for the effort, MoSCoW puts all thirty in one bucket and tells you nothing. Use a scored value-versus-effort model or cost of delay, and keep MoSCoW for the release gate.

When you need to sequence inside Must. Two requirements can both be genuine Musts and still need an order, because one depends on the other or one carries the risk worth retiring first. MoSCoW scopes; it does not schedule.

And MoSCoW says nothing about whether a requirement is any good. Prioritizing an unverifiable line means protecting capacity for something nobody can test. If your list holds items with no failing case at all — "the system shall be performant" — that's upstream, and Functional vs Non-Functional Requirements Explained is the fix.

Running the session

The mechanics are ordinary; the sequence matters, because each step removes a class of argument before the next begins.

1. Send the failing-case question out with the candidate list, three days ahead. Ask for the name and the workaround sentence, not the label — you're collecting evidence, not votes.

2. Put the timebox and the capacity number on the wall first. Without them the session has no denominator and will not converge.

3. Label individually and silently, then aggregate — silence prevents anchoring on the most senior voice present.

4. Discuss only the divergences. Unanimous items are done; the disagreements hold the information.

5. Run the two-part test on every Must and record the answer next to the item, so it isn't re-litigated in week nine.

6. Total the Must effort against capacity. Over ~60%, pick from the four moves. Split first.

7. Write the Won't register, with review dates and owners, before anyone leaves the room.

The output isn't four lists. It's four lists plus a one-line justification per Must and a dated Won't register — and the justifications are the part that has to survive week nine.

What changes

MoSCoW came from Dai Clegg in 1994, published in CASE Method Fast-Track, and became a core practice of DSDM, now stewarded by the Agile Business Consortium. It has lasted thirty years not because four labels are clever — they're barely a framework — but because it encodes one genuinely hard idea: scope is negotiable and the date is not, and somebody has to say out loud what they can live without.

The forty-one Musts weren't dishonest. They were the only rational answer to the question that was actually asked. Change the question to one with a checkable answer, put a capacity number on the wall so arithmetic can contradict people, and give the losing side a dated register instead of a defeat — and the same room, the same stakeholders, and the same sixty-three requirements sort themselves in an afternoon.

Next: once the release is scoped, the pressure moves to what "done" means for each item — see Definition of Done vs Acceptance Criteria.

Sources

• Agile Business Consortium, MoSCoW Prioritisation — DSDM Project Framework Handbook — Minimum Usable SubseT, "Won't have this time", and the ~60% Must / ~20% Could effort guidance.

• Dai Clegg and Richard Barker, CASE Method Fast-Track: A RAD Approach (Addison-Wesley, 1994, ISBN 978-0-201-62432-8) — the original publication of the MoSCoW technique.

• International Institute of Business Analysis (IIBA), A Guide to the Business Analysis Body of Knowledge (BABOK Guide) — prioritization approaches and the basis on which requirements are ranked.

• ISO/IEC/IEEE 29148:2018, Requirements engineering — characteristics of a well-formed requirement, including verifiability, which a priority label cannot supply.