MoSCoW Method: Feature Prioritisation for Timeboxed Delivery

Dai Clegg built MoSCoW to solve a specific problem. A rapid application development team needed to negotiate scope against a deadline that would not move. He published the technique with Richard Barker in Case Method Fast-Track in 1994.

It stayed a niche RAD tool until the Dynamic Systems Development Method Consortium adopted it as a core scoping practice from 2002. That adoption carried MoSCoW into RAD and other structured-delivery contexts, not into general agile practice.

General agile practice adopted RICE, WSJF, story mapping, and continuous discovery as its primary prioritisation frameworks instead, and MoSCoW is now used more selectively, strongest where it started: a fixed deadline with scope still open to negotiate. It fits continuous-delivery or discovery-led product work less well, where teams are more likely to reach for RICE or WSJF. Fygurs’ and Productlift’s current guidance both describe a progression rather than a single choice, from MoSCoW for scope identification and tactical sprint planning, to RICE for data-driven trade-offs, to WSJF for sequencing continuous-delivery work across teams.

The method solves a problem that simpler scales create. A large, medium or low scale leaves medium undefined, and every stakeholder reads it as “important to me”. A numbered list turns prioritisation into an argument about rank.

MoSCoW asks a sharper question of every requirement instead: what happens if this is not delivered? The answer sorts the requirement, and the label carries a promise the business can hold the team to.

What this unblocks:

A fixed delivery date that nobody can protect because every requirement has been labelled Must Have, and a scope argument that keeps reopening because there is no agreed way to settle it.

What the output lets you do:

Commit to the date and say precisely what will and will not be in it, then re-prioritise at the end of each increment without renegotiating the whole scope from scratch.

What you have at the end:

Every requirement sorted into Must, Should, Could, or Won’t Have this time, each disputed Must Have tested against the cancellation test, the effort share checked against the 60/20/20 split, a recorded Won’t Have this time list, and a named arbitrator for the next dispute.

What the four MoSCoW categories mean

Must Have: the minimum usable subset

DSDM defines Must Have requirements as the Minimum Usable Subset, the smallest set of features a solution needs before it is worth deploying at all. A requirement earns that label only if one of these holds:

• There is no point deploying on the target date without it.
• The solution is not legal without it.
• The solution is unsafe without it.
• No workaround exists, not even a manual, painful one.

Categorising a requirement as Should Have or Could Have does not remove it from the plan. Delivery is guaranteed only for the Must Haves.

Should Have and Could Have: the contingency.

Should Have requirements matter, and their absence is felt, yet the solution keeps working without them, often through a temporary workaround such as a manual process or an existing tool. Could Have requirements sit a step lower again: wanted rather than needed, and lower-impact if they slip.

They form the pool a team draws down first when a deadline is at risk.

Won’t Have this time: scope, not rejection

Won’t Have requirements are the ones the team has explicitly agreed not to deliver within the current timeframe. Recording them, rather than letting them drop silently, closes the door on their informal reintroduction later.

That record keeps attention on the Must Haves.

How to decide which category a feature belongs in

The cancellation test

DSDM’s own guidance gives one question to ask of every candidate Must Have, and it is the question I use to settle a disputed Must Have: if this requirement is not met, would you cancel the deployment? A “yes” makes it a Must Have. Anything else, including a manual, painful workaround, is a Should Have or a Could Have.

I ask a second, sharper version of it when the room will not settle. If a Must Have broke the night before deployment, would the team stop the release? An honest no tells me it was never a Must Have.

Separating Should Have from Could Have

The boundary between Should Have and Could Have carries more judgement than the Must Have test, so I agree we should align on the criteria before requirements enter the backlog, not while arguing over one already in it. A useful question: at what number of people affected, or what value of benefit lost, does a Could Have become a Should Have?

Answering that once, as a team, stops the same argument recurring on every requirement.

Why decomposition matters

A requirement that looks like an obvious Must Have often bundles several smaller ones at different priorities. I break a high-level requirement into its parts, then prioritise each separately, to keep the Must Have list genuinely minimal rather than a rewording of everything anyone wants.

The effort-share rule that makes MoSCoW work

The 60/20/20 split

DSDM attaches a specific discipline to the four categories, and I apply that split to every backlog. Must Have requirements should account for no more than 60 per cent of the effort available in a timebox, with a further pool of around 20 per cent held as Could Have contingency, and the remainder sitting with Should Have.

I measure the split against estimated delivery effort, never against the raw count of requirements. Treating it as a headcount exercise, so that 60 per cent of the requirements list becomes Must Have regardless of size, defeats the purpose entirely.

What the other 40 per cent buys

I treat the 40 per cent of effort sitting in Should Have and Could Have as the project’s contingency. When an estimate proves wrong, a dependency turns out harder than expected, or somebody is unavailable, I drop a Could Have first, then a Should Have, so the Must Haves still ship on the committed date.

When I see a team’s Must Have effort creep past 60 per cent, I know real trade-offs have not been made yet. That, in DSDM’s own words, is a materially higher risk of missing the date altogether.

How MoSCoW behaves inside a timeboxed delivery

Three layers of priority

A requirement in a DSDM project can carry three separate MoSCoW ratings at once: one for the whole project, one for the current Project Increment, and one for the specific Timebox underway. A requirement that is a Must Have for the project overall, an archiving facility, say, can reasonably sit as a Could Have or even a Won’t Have for an early increment, because the solution works without it for a few months.

At the Timebox level, most requirements are Won’t Have, because only a handful are in scope for the current stretch of work.

Re-prioritising at the end of each increment

Priorities are not fixed at the start and left alone. At the close of each Project Increment, we re-prioritise every requirement that was not delivered against what the next increment needs.

A Could Have that missed one increment might drop to Won’t Have because the need has passed, or rise to Must Have because the next increment depends on it.

Who arbitrates when a requirement’s category is disputed

Any requirement proposed as a Must Have gets openly discussed by the project manager, the business analyst, and the rest of the delivery team whenever it is not obvious, and it falls to the Business Visionary, or their empowered Business Ambassador, to justify the classification.

Where the disagreement will not settle, DSDM’s guidance sets out a fixed escalation path. The Business Ambassador and Business Analyst raise it with the Business Visionary, and, if that does not resolve it, the Business Visionary escalates to the Business Sponsor. Agreeing this chain before work starts, rather than mid-argument, keeps a Must Have dispute from stalling delivery.

Where the MoSCoW method fails

Prioritising before the need is validated

A live critique of prioritisation frameworks generally holds that starting with any of them, MoSCoW included, risks premature commitment before the need is validated. Continuous discovery increasingly does that job first: it narrows scope before a requirement ever reaches a MoSCoW pass.

Everything becomes a Must Have.

The most common failure, and the one I see most often, is the one DSDM’s own documentation names directly: every requirement arrives labelled Must Have, so there is nothing left to drop when the deadline is threatened, and the effort-share rule cannot be honoured. Have seen this happen more than once, and it is usually a symptom of insufficient decomposition.

Large, bundled requirements resist differentiated prioritisation, because saying no to any part of a bundled thing feels like saying no to all of it.

The fix is smaller requirements, not a bigger timebox

Extending the deadline treats the symptom, not the cause. I break requirements down until each piece can be judged against the cancellation test on its own terms.

When a team cannot find any Could Have or Won’t Have candidates, I know it has not finished decomposing its requirements.

What MoSCoW cannot weigh

MoSCoW sorts by category, not by number, so it misses the cost of delay and time-to-market factors that RICE and WSJF capture, along with the effort quantification those frameworks force. I reach for RICE or WSJF alongside MoSCoW when a decision needs that weighting, not instead of it.

Common questions

Who created the MoSCoW method:

Dai Clegg developed it in 1994 while working at Oracle Application Development, and Oracle published it with Richard Barker in Case Method Fast-Track: A RAD Approach.

What do the four MoSCoW letters stand for:

Must Have, Should Have, Could Have, and Won’t Have this time. The interstitial Os exist only to make the acronym pronounceable.

How much of the effort can be Must Have:

DSDM recommends no more than 60 per cent of delivery effort, leaving roughly 20 per cent as Could Have contingency and the rest as Should Have.

Is the 60 per cent rule based on the number of requirements or the effort:

Effort, not count. Reading it as a rule about how many requirements can be labelled Must Have misreads the discipline entirely.

Who decides if a requirement is a genuine Must Have:

The Business Visionary, or their empowered Business Ambassador, justifies the classification. Unresolved disputes escalate to the Business Visionary, then the Business Sponsor.

What happens if every feature ends up a Must Have:

The effort-share rule breaks down, and there is nothing left to drop when a deadline is threatened. It usually signals requirements that need to be broken into smaller pieces.

Is MoSCoW only used on agile software projects:

No. It began in rapid application development and now prioritises requirements, tasks, tests and even to-do lists on any project working to a fixed deadline.

Key facts, current as of September 2026