Decision-making & prioritisation
MoSCoW Prioritisation
A four-category prioritisation scheme, Must have, Should have, Could have and Won't have this time, built for fixed deadlines: it guarantees a minimum usable delivery by agreeing in advance exactly what gives way when time runs short.
Also known as MoSCoW method, MoSCoW analysis, Must-Should-Could-Won't. First set out by Dai Clegg (Oracle UK) in 1994.
- Format
- Checklist / audit
- Level
- Product · Team
- Best for
- Prioritise · Plan execution
- Decision stage
- Decide · Plan
- Difficulty
- Introductory
- Time to apply
- A half-day workshop for a typical requirements list; the arguing over the Must have test, which is where the value lives, takes most of it.
Plate · The model
The components
Must have
Requirements without which the delivery is unlawful, unsafe or pointless on the day. Together they form the minimum usable subset: if any Must is missing, the delivery date moves or the delivery is cancelled.
Signals of strength
A legal, regulatory or safety obligation attached · No workaround exists, however painful · The business case collapses without it · Shipping without it means not shipping at all
Should have
Important requirements whose omission hurts and must be justified, but for which a workaround exists. Shoulds are expected to be delivered, and are the second thing sacrificed when time runs out.
Signals of strength
Omission is painful and visible, and survivable · A manual or temporary workaround exists · Deferral needs explaining to stakeholders, never the cancellation of the launch · Would be a Must on a longer timescale
Could have
Desirable requirements with materially smaller consequences if left out. In DSDM practice the Could haves are the plan's contingency pool, around 20 per cent of total effort, which is what makes the Must have guarantee credible.
Signals of strength
Wanted, with only mild impact if dropped · First to go when estimates slip · Sized deliberately as schedule contingency · Nobody outside the team would cancel anything over it
Won't have this time
Requirements agreed to be out of scope for this deadline. The canonical DSDM long form is 'Won't have this time', and the last two words carry the value: the item is recorded, expectations are set, and the conversation can be reopened for the next increment.
Signals of strength
Explicitly recorded, never silently dropped · Attached to this timeframe rather than rejected forever · Referred to when scope pressure appears mid-delivery · Reviewed when planning the next increment
When it earns its keep
- The deadline is genuinely fixed, by law, contract or a public commitment, and scope is the only variable left to manage.
- Stakeholders all describe their own requirements as critical, and you need a shared test that separates 'the launch fails without it' from 'I would mind'.
- You are planning a timeboxed increment and need to agree, before work starts, which items will be dropped first if estimates prove optimistic.
- A supplier relationship needs an explicit, written record of what is out of scope this time, so that descoping later is a plan rather than a breach of trust.
And when it doesn't
- You need a rank order, and no more. MoSCoW sorts items into four bins and says nothing about sequence within a bin; use RICE or a weighted matrix when fine-grained ordering matters.
- The deadline is soft. Without real time pressure every category quietly inflates, because nothing forces the distinction between Must and Should to bite.
- The candidate items differ enormously in cost. MoSCoW categorises by necessity alone, and a trivial Must plus a ruinous Must look identical until effort is examined alongside.
- You are choosing between mutually exclusive options rather than triaging a scope. That is a decision-matrix problem, and MoSCoW has no machinery for it.
How to run it
Before starting, gather the inputs the analysis depends on:
- A defined delivery and a stated timeframe, because every MoSCoW priority is relative to a specific deadline rather than absolute.
- A requirements list at reasonably consistent granularity, with rough effort estimates attached.
- An agreed, written test for Must have, set before any categorisation begins.
- The decision-makers in the room: business owners who can accept a Won't, and delivery people who know what things cost.
- A record-keeping habit, since the value of the Won't have list depends on it being written down and revisited.
- 1
Fix the frame
State exactly what delivery is being prioritised and by when. The final category is 'Won't have this time' for a reason: every priority is an answer to the question 'for this deadline?', and without a stated deadline the categories mean nothing. (The lowercase o's in MoSCoW are padding, added only to make the acronym pronounceable.)
- 2
Agree the Must have test
Before categorising anything, agree what Must means: the delivery is illegal, unsafe or pointless without it. DSDM's retrofitted test is the Minimum Usable SubseT, and the practical question is 'what happens if we ship without this?'. If the answer is anything short of 'we cancel the launch', it is not a Must.
- 3
Categorise every requirement
Work through the list item by item, business and delivery voices together, applying the agreed test. A Should have is important and painful to omit, but a workaround exists. A Could have is wanted, with materially smaller consequences if dropped. A Won't have this time is out of scope for this deadline, recorded openly rather than left to be discovered in the final week.
- 4
Check the balance of effort
Categorisation only works if the arithmetic does. DSDM's guidance is that Must haves should account for no more than about 60 per cent of the planned effort, with around 20 per cent held as Could have contingency. A plan that is 95 per cent Must have has not been prioritised; it has been relabelled.
- 5
Use the categories in flight
When estimates prove optimistic, and they will, drop Could haves first, then Should haves, without renegotiating from scratch. This is the payoff for the earlier arguing: the descoping order was agreed when heads were cool, so the deadline is protected by design rather than by heroics.
- 6
Reset for the next increment
After delivery, the categories expire. Revisit the Won't have list and the dropped items for the next timeframe with fresh eyes: some Won'ts become Musts, and some turn out never to be missed, which is worth noticing too.
Reading the result
A categorised requirements list with an agreed descoping order, an explicit minimum usable subset, an effort balance check across the four categories, and a written record of what is out of scope for this timeframe.
- Read the effort split before the categories. Musts near 60 per cent of effort means the plan carries real contingency; Musts near 90 per cent means the deadline is being defended by hope.
- The Won't have list is a promise register, and worth as much as the Must list. If it is empty, scope was never really negotiated.
- Categories are relative to the stated deadline. A Should for the March release may be a Must for the September one, so date every categorisation.
A worked example
A district council rebuilds its public website against a fixed switch-off date
An English district council must replace its website before the incumbent platform's support contract expires in nine months, with no option to extend. The budget is fixed, public-sector accessibility regulations apply, and every department believes its pages are critical. The digital team runs a MoSCoW workshop with service heads, using rough effort estimates for each requirement and the DSDM effort guidance as the referee.
- Must have
- Pay council tax online, report a missed bin collection, search planning applications, WCAG 2.2 AA accessibility across the site, and migration of all statutory content. The test applied was 'does the council fail a legal duty or lose a critical service on day one without this?'. Housing's request for a full tenant portal failed the test, to loud objection, because the existing phone service constitutes a workaround. Must effort lands at 55 per cent.
- Should have
- Rebuilt site search, webchat to the customer service centre, and replacement of the twenty most-used PDF forms with accessible online forms. Each is important and each has a workaround: old search patterns, the phone line, the existing PDFs. Around 25 per cent of effort.
- Could have
- Ward-level interactive maps, personalised bin-day reminders, and a redesigned news hub. Roughly 20 per cent of effort, held explicitly as contingency, and the service heads are told to their faces that these are the items that vanish first if migration overruns.
- Won't have this time
- Single sign-on across all resident services, a native mobile app, and full self-service licensing applications. Each is recorded in the roadmap with a named review date at the next budget round. The register keeps councillors from reopening scope in month seven, because 'not now' was agreed in public rather than discovered late.
The read. Content migration overran by six weeks, as content migrations do. The team dropped the maps and the news hub, deferred the PDF form replacements to a fast-follow release, and shipped a compliant, working site before the switch-off date. The method's value was visible in what did not happen: no crisis renegotiation, no heroics, and no stakeholder able to claim surprise, because the descoping order had been agreed when it was still hypothetical.
Pitfalls
- Must have inflation. Without a hard, pre-agreed test, categorisation becomes a status contest and most of the scope lands in Must, which destroys the contingency the method exists to create.
- Categorising without effort estimates. The 60 per cent check is what makes MoSCoW a plan rather than a wish list, and it cannot be run on categories alone.
- Treating Should have as 'Must have, but said politely'. If Shoulds are never actually dropped under pressure, the team has two categories and believes it has four.
- Leaving the timeframe implicit. 'Won't have' without 'this time' reads as rejection, poisons stakeholder relationships, and hides the fact that priorities expire with the deadline.
- Letting seniority substitute for the test. The categories only hold in week thirty if the reasoning was genuinely shared in week one.
What the critics say
The method's own stewards concede its central failure mode: DSDM guidance exists precisely because Must have inflation is routine, and it recommends holding Must have effort to about 60 per cent with around 20 per cent Could have contingency. In practice this discipline is widely ignored, and a MoSCoW exercise that skips the effort arithmetic delivers the vocabulary of prioritisation without the substance.
Agile Business Consortium, 'MoSCoW Prioritisation', DSDM Project Framework Handbook. https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html
Miranda's Monte Carlo analysis of the method shows that the implied guarantee of delivering all Must haves is conditional rather than structural: it holds only when estimates are reasonably accurate and the Could have contingency pool is sized generously relative to estimation error. Under realistic uncertainty, plans following the 60/20/20 pattern can still fail to deliver their minimum usable subset.
Miranda, E. (2022) 'Moscow Rules: A Quantitative Exposé', in Agile Processes in Software Engineering and Extreme Programming, XP 2022, Lecture Notes in Business Information Processing 445. Cham: Springer.
Requirements-engineering research classes MoSCoW among the coarse ordinal techniques: it offers no ordering within a category, no way to express that one Should matters far more than another, and no machinery for trading value against cost. It triages a scope well and ranks one poorly, and teams that need a sequence must bolt another method on top.
Work it through
Sort each requirement into the four boxes, then check the balance: if Must have work is much above 60 per cent of the effort, the plan has no contingency and the exercise is not finished. Your entries persist for this browser session and can be copied out as Markdown or printed.
0 of 4 blocks filled
Sources and further reading
- Clegg, D. and Barker, R. (1994) Case Method Fast-Track: A RAD Approach. Wokingham: Addison-Wesley.
- Agile Business Consortium, 'MoSCoW Prioritisation', DSDM Project Framework Handbook. ↗
- Agile Business Consortium, 'What is MoSCoW Prioritization?'. ↗
- Miranda, E. (2022) 'Moscow Rules: A Quantitative Exposé', XP 2022, LNBIP 445. Cham: Springer. ↗