MoSCoW Method: The Complete Prioritization Guide
Learn the MoSCoW prioritization method: Must, Should, Could, Won't, a step-by-step workshop, the 60/20/20 rule and how to avoid the everything-is-Must trap.
By the RoadmapHero team · Updated on · 8 min read
Key takeaways
- MoSCoW sorts requirements into Must have, Should have, Could have and Won't have (this time) relative to a fixed deadline, release or goal, rather than ranking them.
- An item is a Must have only if you would cancel the launch without it; if you would ship anyway and patch it later, it belongs in Should have.
- Follow DSDM's 60/20/20 rule: Must haves take no more than about 60% of delivery effort, leaving roughly 20% for Should haves and 20% for Could haves as a buffer.
- MoSCoW is a scoping tool, not a sequencing tool: use it to decide what is in scope, then a quantitative score such as RICE to order the work inside each category.
The MoSCoW prioritization method answers one question better than any other framework: "what is truly in scope?". When a deadline is fixed, when an MVP has to ship, when stakeholders each defend their pet feature, MoSCoW forces a shared, explicit decision about what is non-negotiable, what is important, what is nice, and what is out. This guide explains the four categories, how to run a MoSCoW workshop step by step, the 60/20/20 effort rule that keeps plans honest, and where the method stops being enough.
What is the MoSCoW method?
MoSCoW was created by Dai Clegg at Oracle in the 1990s and became a core practice of the DSDM agile framework. The acronym covers four categories — Must have, Should have, Could have, Won't have (this time) — with two "o"s added for pronounceability. Its founding idea: on a project with a fixed deadline and fixed resources, scope is the only variable. MoSCoW makes that variable explicit before the pressure hits, instead of negotiating it in panic two weeks before launch. Unlike scoring frameworks such as RICE, MoSCoW does not rank items against each other; it sorts them into buckets relative to a specific goal, release or date.
The 4 MoSCoW categories explained
Must have — the release fails without it
A Must have is a requirement without which the release is not viable: illegal, unsafe, unusable, or pointless. The acid test: "if this is missing on launch day, do we cancel the launch?" If the honest answer is "no, we'd ship anyway and patch it", it is not a Must. Examples for a payments MVP: processing a card payment, PCI compliance, refund handling. Not a Must: a beautiful dashboard about those payments.
Should have — important, painful to omit, survivable
A Should have is important and expected, but the release survives without it — possibly with a workaround (a manual process, a support macro, a delay). Omitting it hurts adoption or efficiency, not viability. Should haves are the first candidates when Musts overrun.
Could have — desirable if capacity allows
Could haves are the comfort layer: smaller improvements with real but limited impact, dropped first when the schedule slips. In DSDM they are exactly the planned contingency buffer — work you fully intend to do, and can sacrifice without renegotiating anything.
Won't have (this time) — explicitly out
The most underrated category. Won't haves are recorded, visible decisions: "not in this release". Writing them down kills the ambiguity that fuels scope creep, and reassures stakeholders that "no" means "not now", not "never". Keep Won't haves in the backlog — many become candidates for the next cycle, and a Now/Next/Later roadmap is a natural home for them.
When to use MoSCoW (and when not)
MVP scoping: separating "the product does not exist without this" from "investors will love this" is exactly the Must/Should boundary.
Deadline projects: regulatory compliance, a trade-show launch, a contractual delivery — fixed date, variable scope.
Release planning: agreeing with stakeholders on what the next version guarantees vs what it may include.
Migration or replatforming: deciding which legacy behaviors must be preserved at parity and which can wait.
Avoid MoSCoW as your only method for the continuous prioritization of a product backlog: four buckets cannot order the 30 items inside the Should bucket, and that ordering is where the real decisions live (see the limits section below).
Running a MoSCoW workshop, step by step
Prepare (before the meeting). List candidate items with a one-line description and rough effort. Circulate the list 48 hours ahead. Invite the decision-makers: PM, tech lead, design, plus the sponsor. Six to eight people maximum.
Fix the frame (10 min). State the scope object ("release 2.0, shipping March 31") and the definition of each category, especially the Must test: "would we cancel the launch without it?". Write both on the wall.
First pass, silent (15 min). Each participant categorizes every item on their own. Silent first passes prevent anchoring on the loudest voice.
Confront and discuss (30–45 min). Reveal votes. Items with consensus are filed instantly. Debate only the splits, starting with Must/Should disagreements — the boundary that matters most. Timebox each debate to 5 minutes; if it stalls, the item is provisionally a Should and gets an owner to bring evidence.
Check the effort balance (15 min). Sum rough effort per category and confront it with the 60/20/20 rule below. This step is where most workshops discover their plan is fiction — and fix it.
Record and publish. Write down every categorization, including Won't haves, with the one-sentence rationale. Share it with everyone affected — an unpublished MoSCoW decision gets relitigated within a month. Good stakeholder communication is half the value of the exercise.
The 60/20/20 rule
DSDM's most practical guideline: on total delivery effort, aim for roughly
Category | Share of effort | Role in the plan |
|---|---|---|
Must have | ≤ 60% | The guaranteed minimum |
Should have | ~ 20% | Expected, first to slip |
Could have | ~ 20% | Contingency buffer |
The logic: if Must haves consume 90% of capacity, one sick developer or one underestimated story breaks the guaranteed scope — the thing you promised never to break. Keeping Musts at 60% means the team can absorb surprises by dropping Coulds, then Shoulds, while always delivering every Must. Teams that apply this rule ship "on time with a bit less"; teams that don't ship "late with excuses".
Pitfalls: when everything becomes a Must
Must inflation: the classic failure. Stakeholders learn that Must = guaranteed, so everything becomes a Must. Antidotes: the cancel-the-launch test, the 60% effort cap, and requiring a written justification per Must.
Category by rank: the sponsor's items are Musts because the sponsor said so. Run the silent first pass and score justifications, not job titles.
Empty Won't bucket: a MoSCoW session that rejects nothing has decided nothing. If Won't is empty, the candidate list was pre-filtered or the group is avoiding conflict.
One-shot categorization: categories are relative to a deadline. When the deadline or the context changes, re-run the exercise — a Should in March can be a Must in June.
No effort data: categorizing without even rough estimates makes the 60/20/20 check impossible and the plan unverifiable.
Limits for a continuous product portfolio
MoSCoW is a scoping tool, not a sequencing tool. Three structural limits show up when teams stretch it beyond releases:
No ordering inside buckets: with 25 Should haves, which do you build first? MoSCoW is silent; you need a score.
No value/cost trade-off: a Must costing 6 months and a Must costing 2 days look identical. Nothing in the method rewards cheap high-value items.
Deadline-relative by design: a continuous product has no single deadline, so "Must for what?" loses meaning, and categories quietly become synonyms for "high/medium/low priority" — the vagueness MoSCoW was invented to eliminate.
For a living backlog, use MoSCoW at the boundaries (what enters the quarter) and a quantitative method inside them — see how to prioritize your backlog for a full comparison of frameworks.
Combining MoSCoW with quantitative scoring
The strongest setups treat MoSCoW and scoring as two stages of one pipeline: MoSCoW decides what is in, scoring decides in what order. Concretely: run the MoSCoW workshop to fix the release scope, then score Musts and Shoulds with RICE or a weighted model to sequence the work and expose hidden bad deals (a Should with a huge score should make you question a mediocre Must). In RoadmapHero, teams model this directly: a custom field or label carries the MoSCoW category, while HeroScore — the configurable multi-criteria score combining business value tied to OKRs, user value from Customer Voice feedback, effort, risk and urgency — orders the backlog within each category. The roadmap view can then be shared with stakeholders in one click, with unlimited viewers, so the scope decision and the sequence stay visible instead of living in a workshop photo. Free trial, transparent pricing in euros, no commitment.
Frequently asked questions
What does MoSCoW stand for?
MoSCoW stands for Must have, Should have, Could have and Won't have (this time). The lowercase "o"s were added to make the acronym pronounceable. The method comes from Dai Clegg's work at Oracle and was popularized by the DSDM agile framework.
How many items should be Must have?
DSDM recommends that Must haves consume no more than about 60% of the delivery effort, leaving 20% for Should haves and 20% for Could haves. If Musts exceed 60%, the plan has no buffer and any surprise turns into a missed deadline.
What is the difference between MoSCoW and RICE?
MoSCoW sorts items into four categories based on necessity for a given scope or deadline; RICE computes a numeric score from Reach, Impact, Confidence and Effort to rank items. MoSCoW is faster and stakeholder-friendly; RICE gives a finer ordering. Many teams use MoSCoW to scope, then RICE to sequence.
Does "Won't have" mean the feature is cancelled?
No. Won't have means "not in this release or timeframe". It is an explicit, recorded decision that protects the scope while keeping the idea in the backlog for a future cycle — which makes it far easier for stakeholders to accept.
Is MoSCoW still relevant for agile product teams?
Yes, for scoping decisions: MVP definition, release planning, deadline projects. For the continuous prioritization of a living product backlog, its four buckets are too coarse, and most teams complement it with a quantitative score such as RICE, WSJF or a configurable score like RoadmapHero's HeroScore.