MoSCoW Prioritization: Must, Should, Could, Won’t Have
MoSCoW is a categorical prioritization technique that classifies requirements into four buckets: Must have, Should have, Could have, and Won't have—enabling clear scope management and stakeholder alignment.
Before you start
Is MoSCoW your framework?
MoSCoW answers one question: given a deadline that will not move, what ships and what does not? It is a scope-management technique, not a ranking method. It sorts requirements into four commitment levels; it does not order them within those levels, and it says nothing about effort, value or sequence.
That makes it excellent when the date is fixed and the scope must flex, and close to useless when the scope is fixed and the date must flex. Most disappointment with MoSCoW comes from teams in the second situation using a tool built for the first.
| If your real problem is… | You probably want |
|---|---|
| We need a ranked order, not four buckets | RICE — produces a single sorted list with a number behind each row Compare MoSCoW and RICE |
| We need to find the quick wins | Value vs Effort Matrix — MoSCoW has no effort axis at all Compare MoSCoW and Value/Effort |
| We do not know which features customers actually care about | Kano Model — MoSCoW records opinions in the room; Kano gathers evidence from customers Compare MoSCoW and Kano |
| Our problem is urgency versus importance across tasks | Priority Matrix — a different two-axis question entirely |
| We need to see the release as a user journey, not a list | User Story Mapping — then apply MoSCoW to the slices it produces |
| Work arrives continuously and there is no release date | Kanban — MoSCoW needs a timebox to mean anything |
| A backlog nobody can rank | The feature prioritization playbook, where MoSCoW is stage 4 of 5 |
| The date cannot move and we have to decide what ships | MoSCoW — you are in the right place |
The test that separates real MoSCoW from a wish list with four headings
Is there a fixed timebox, and is there a stated ceiling on Must Have? Without a deadline that cannot move, “Won’t have this time” has no “this time” to refer to, and Must Have has no budget it can exceed. DSDM’s own guidance caps Must Have at around 60% of effort for exactly this reason. A MoSCoW list with no date and no percentage cap will converge on all-Must-Have within two meetings.
What Is It?
MoSCoW is a prioritization technique that sorts requirements into four commitment levels: Must have, Should have, Could have and Won’t have (this time). Dai Clegg devised it in 1994 while at Oracle, and it was adopted into DSDM, the agile method that later became the DSDM Agile Project Framework. The lower-case o’s are filler, added only to make the acronym pronounceable.
Its purpose is scope management under a fixed deadline. In a timeboxed delivery the date is the constant and the scope is the variable, so somebody has to decide in advance which parts of the scope are allowed to fall away when time runs short. MoSCoW makes that decision explicit and makes it early, while it can still be argued about calmly.
The fourth category carries more weight than the other three. “Won’t have this time” is not rejection — it is a dated commitment to revisit, which is what makes stakeholders willing to let go of an item at all. Teams that shorten it to “Won’t have” find the negotiation gets markedly harder, because it now sounds permanent.
What MoSCoW deliberately does not do is rank. There is no ordering inside Must Have, no effort estimate, no value score and no dependency map. It is a coarse instrument, and its speed is a direct consequence of that coarseness.
Quick Reference
The canonical structure
The four categories, and what each one commits you to
The categories are commitments about delivery, not labels of importance. The test for each one is a question about what happens if it is missing on the release date.
The acronym is sometimes written MSCW. Both refer to the same four categories.
| Category | The test | Share of effort |
|---|---|---|
| Must have | If this is missing on the date, is the release illegal, unsafe, unusable or not worth shipping? If there is any workaround at all, however ugly, it is not a Must. | No more than about 60%. This ceiling is the mechanism that makes the whole method work. |
| Should have | Painful to omit, but there is a workaround — a manual process, a temporary policy, a phone call. It hurts; it does not stop the release. | Roughly 20% |
| Could have | Desirable, small impact if dropped. These are the contingency: the buffer that absorbs the overrun without anyone having to renegotiate the date. | Roughly 20%, and this is deliberate slack rather than spare capacity |
| Won’t have (this time) | Explicitly out of scope for this timebox, and explicitly recorded so it can return in the next one. | 0% of this timebox — but writing them down is what makes the other three categories negotiable |
On the effort ceiling
The 60/20/20 split is the part most often left out when MoSCoW is taught. Without it, the four categories are just adjectives, and there is nothing to stop a stakeholder arguing every item into the top box. With it, Must Have becomes a budget: adding one thing requires taking something else out.
A common confusion
Is MoSCoW an agile framework?
No — and the confusion is worth untangling, because it is one of the most frequently asked questions about the method.
MoSCoW is a prioritization technique, not a framework. The agile framework it is associated with is DSDM, the Dynamic Systems Development Method, which adopted MoSCoW as its standard approach to scope management. DSDM predates the Agile Manifesto — it was published in 1994, the same year Clegg devised MoSCoW — and later became a signatory method under the Agile Alliance. So if a question asks which agile framework uses MoSCoW, the answer is DSDM, now known as the DSDM Agile Project Framework.
Scrum does not include MoSCoW. A Scrum product backlog is a single ordered list, deliberately: the Product Owner ranks items one against another rather than grouping them into tiers. Plenty of Scrum teams borrow MoSCoW anyway, usually for sprint or release planning, but it is a borrowed tool rather than part of the framework. SAFe likewise references it as one prioritization option among several rather than as a required practice.
The practical implication is not academic. MoSCoW assumes a timebox with a fixed end date and flexible content, which is exactly the DSDM delivery model. Applying it to a continuously flowing backlog with no fixed release date removes the constraint that gives the four categories meaning.
Core Features
- Four commitment levels, not a ranked list: items sit in tiers, unordered within each tier
- Timebox-relative by definition: every category is a statement about one specific delivery window
- An effort ceiling on Must Have: the ~60% guideline is what stops category inflation
- Could Have as designed contingency: the buffer is inside the plan rather than hidden in estimates
- “This time” is part of the fourth category: deferral, not rejection, which is what makes it agreeable
- Immediate to learn: no training, no scoring model, no tooling — a whiteboard is sufficient
- Language stakeholders already use: the words carry their ordinary meanings, which is most of why it spread
Worked example
A MoSCoW list that had to be redone
An illustrative composite. A credit union in Des Moines replacing its member-facing online banking portal, with a hard cutover date set by the end of its vendor contract. Nine weeks of build capacity. The left column is the first workshop; the right is after the effort ceiling was applied.
The first pass put 87% of estimated effort into Must Have. Nothing was obviously wrong with any individual judgment — the list was simply not a plan.
| Requirement | First workshop | After the ceiling was applied |
|---|---|---|
| Log in, view balances, view transactions | Must | Must — no workaround exists; without it the portal is not a portal |
| Transfer between own accounts | Must | Must |
| Multi-factor authentication | Must | Must — regulatory, so the test is passed on the first question |
| Mobile check deposit | Must | Should. The workaround is the branch and the ATM network, both of which already exist. Painful, not fatal. This single move freed roughly 11% of effort. |
| Bill pay to external payees | Must | Should. Members can keep using the legacy bill-pay portal for one more quarter under an extended agreement — an ugly workaround, which is precisely what Should Have means. |
| Alerts and notification preferences | Should | Could — moved down to rebuild the contingency the plan had lost |
| Spending categorization and charts | Could | Could |
| Joint-account permission management | Should | Won’t have this time — scheduled explicitly for the following release, with a date attached |
| Dark mode | Could | Won’t have this time |
What the ceiling actually did
Two reclassifications did most of the work, and both turned on the same question: is there a workaround, however unpleasant? Branch deposits and a legacy bill-pay portal are both bad answers, and both are answers. Once that question was asked consistently rather than sentimentally, Must Have fell to 58% of effort and the plan had 20% of genuine slack in the Could Have tier.
The two Won’t Have items were the reason the workshop ended without a fight. Both left with a named release and a date, so the people who wanted them had conceded a sequence rather than a feature.
When to Use
- A fixed, non-negotiable delivery date where scope is the only variable available
- Release or sprint planning that needs a shared answer to “what actually ships?”
- Negotiating scope with stakeholders who are not going to engage with a scoring model
- Regulatory or contractual deadlines, where Must Have has an objective external test
- Migrations and replatforming, where parity with the old system is the temptation to resist
- Early in a project, to surface disagreement about importance while it is still cheap
- As a second pass over the output of User Story Mapping or RICE
When NOT to Use
- Continuous flow with no release date — without a timebox the categories lose their meaning; use Kanban
- When you need a ranked order rather than tiers — use RICE
- When effort is the deciding factor — MoSCoW has no effort axis; use Value vs Effort
- When nobody in the room has authority to say no — the method needs a decision-maker, not a committee
- When the categories cannot be tested against customer evidence — use Kano first
- Scope-fixed, date-flexible projects — the tool is built for the opposite trade
In practice
How MoSCoW goes wrong
MoSCoW takes an afternoon to run and has one dominant failure mode with several disguises. Nearly all of them are versions of Must Have expanding until it means nothing.
| What you see | What it usually means | What to do |
|---|---|---|
| Most of the list is Must Have | No effort ceiling was set, so nothing constrains the category | Apply the ~60% guideline and make it a budget. Adding a Must requires removing one. Estimate roughly — the ratio matters more than the accuracy. |
| Endless argument between Should and Could | The wrong distinction is being debated | Ask only one question: is there a workaround? If yes, it is Should at best. The Should/Could line is far less consequential than the Must line, so timebox that argument. |
| Won’t Have is empty | Nobody has been told no, so no real prioritization has happened | An empty fourth category means the exercise produced a wish list. Force at least a few items into it, each with a named future release. |
| “Won’t have” is being read as “never” | The words “this time” were dropped | Restore them everywhere, including on slides. The whole negotiating power of the category lives in those two words. |
| The categories never change after the workshop | Treated as a signed document rather than a live plan | Re-run at each timebox boundary. Priorities that were right in week one rarely survive to week nine unchanged. |
| Everything ships anyway, including the Coulds | Contingency was consumed as capacity | Could Haves are the buffer. If they always ship, the estimates were padded and the next timebox will be planned on false confidence. |
| Senior stakeholders overrule the categories mid-timebox | The list has no owner with authority | Name the person who decides before starting. MoSCoW resolves nothing on its own; it only makes the decision visible. |
Sourced
Origins, and how to cite it
Dai Clegg devised it at Oracle in 1994, for rapid application development.
Clegg introduced the technique in Case Method Fast-Track: A RAD Approach, written with Richard Barker and published by Addison-Wesley in 1994. It was designed for Oracle’s RAD practice, where fixed timeboxes were already the norm — which is why the method assumes a movable scope and an immovable date rather than the reverse.
Clegg, D. & Barker, R. (1994) Case Method Fast-Track: A RAD Approach. Wokingham: Addison-Wesley.
DSDM is the agile framework that adopted it, and DSDM is where the effort ceiling comes from.
The DSDM Consortium built MoSCoW into its method as the standard approach to scope management, and added the guidance that Must Have should account for no more than around 60% of effort, with roughly 20% left as Could Have contingency. That numeric guidance is DSDM’s contribution rather than Clegg’s, and it is the part most often omitted when the technique is taught second-hand.
DSDM Consortium, The DSDM Agile Project Framework (Agile Business Consortium).
The method has no ranking, no effort dimension and no dependency handling — by design.
MoSCoW will not tell you which of two Must Haves to build first, how much either costs, or that one cannot start until the other finishes. Its own comparison profile is unusually blunt about this: high clarity, low objectivity. That is a fair trade when the goal is a scope conversation with non-specialists, and a poor one when the goal is a work order. Teams that need both generally rank with RICE or Value vs Effort and then apply MoSCoW to the result.
The most common failure is documented in the method itself.
Category inflation — everything becoming a Must Have — is not an exotic edge case. It is the predictable equilibrium of asking stakeholders to label their own requirements with no constraint attached, and the 60% ceiling exists precisely because the DSDM community observed it happening repeatedly. A MoSCoW list presented without an effort ratio should be treated as unfinished rather than merely imperfect.
How to cite it.
Harvard: Clegg, D. and Barker, R. (1994) Case Method Fast-Track: A RAD Approach. Wokingham: Addison-Wesley.
APA: Clegg, D., & Barker, R. (1994). Case method fast-track: A RAD approach. Addison-Wesley.
For the effort guidance and agile context, cite the DSDM Agile Project Framework published by the Agile Business Consortium rather than the 1994 book, which does not contain it.
Key Strengths
- Immediately understood: no training, no scoring, no tool — the words mean what they normally mean
- Built for negotiation: “Won’t have this time” gives stakeholders a way to concede without losing
- Makes contingency explicit: the Could Have tier is slack that everyone has agreed to in advance
- Fast: a workable first list in two to three hours with the right people present
- Forces the negative decision: most prioritization methods rank; this one requires saying no out loud
Key Weaknesses
- Category inflation — without an effort ceiling, everything becomes a Must Have
- No ordering within a category, so it cannot tell you what to build first
- No effort, cost or value dimension of any kind
- Ignores dependencies, which can make a Could Have secretly compulsory
- Highly political: the categories reflect who is in the room and how loud they are
- Meaningless without a fixed timebox, which rules out continuous-delivery contexts
How It Works
| 1 Primary Input | List of requirements or features to categorize |
|---|---|
| 2 Data You Need | Team discussion and stakeholder judgment |
| 3 Primary Output | Categorized list (Must, Should, Could, Won't) |
Comparison with Related Frameworks
MoSCoW is one of the fastest prioritization frameworks. Here's how it compares to alternatives:
MoSCoW vs RICE
RICE Score provides quantitative rankings with numerical scores, while MoSCoW uses categorical buckets. Use MoSCoW when speed matters, RICE when you need data-driven justification for stakeholders.
MoSCoW vs Value vs Effort
Value vs Effort Matrix visualizes items on two axes, while MoSCoW categorizes without considering effort explicitly. Use Value vs Effort when implementation cost varies significantly between items.
MoSCoW vs ICED
ICED Prioritization adds customer delight to the scoring equation. Use MoSCoW for quick scope decisions, ICED when you want to explicitly factor in user experience impact.
MoSCoW vs Priority Matrix
Priority Matrix uses urgency and importance axes, while MoSCoW focuses on requirement criticality. Both are fast—use MoSCoW for feature scope, Priority Matrix for task management.
Sequencing
What to run before and after
MoSCoW sorts a list it did not create and does not schedule. It works best sandwiched between something that generates candidates with evidence and something that turns tiers into an order of work.
Before
Build the candidate list, with evidence
MoSCoW records the room’s opinion. If the room has no customer evidence or no story map, the categories will encode seniority rather than importance.
During
Sort into four tiers, then check the ratio
The sorting takes an afternoon. The step that makes it real is estimating effort per tier and pushing Must Have back under roughly 60%.
After
Turn tiers into a sequence and defend the buffer
Must Have is a set, not an order. Something has to sequence the work and protect the Could Have contingency from being spent as capacity.
Part of a playbook: How to Prioritize Product Features. MoSCoW is stage 4 of 5, after RICE and before user story mapping.
Common questions
MoSCoW: quick answers
Which agile framework is called MoSCoW?
None of them. MoSCoW is a prioritization technique, not a framework. The agile framework that adopted it as its standard scope-management approach is DSDM, the Dynamic Systems Development Method, now published as the DSDM Agile Project Framework. Dai Clegg devised MoSCoW at Oracle in 1994 and DSDM built it in. Scrum does not include MoSCoW, because a Scrum product backlog is a single ordered list rather than a set of tiers, though many Scrum teams borrow the technique for release planning.
What does MoSCoW stand for?
Must have, Should have, Could have, and Won’t have this time. The lower-case o’s carry no meaning at all; they were added only to make the acronym pronounceable. It is sometimes written MSCW without them. The full form of the fourth category matters: it is Won’t have this time, not simply Won’t have, because the deferral is what makes stakeholders willing to release the item.
What are the four MoSCoW categories?
Must have covers requirements with no workaround, where the release is not worth shipping without them. Should have covers requirements that are painful to omit but have a workaround, even an unpleasant manual one. Could have covers desirable items with small impact if dropped, which function as the plan’s contingency. Won’t have this time covers items explicitly excluded from the current timebox and explicitly recorded for a later one.
How much should be a Must Have in MoSCoW?
DSDM guidance caps Must Have at around 60% of total effort, leaving roughly 20% for Should Have and roughly 20% for Could Have. The Could Have tier is deliberate contingency rather than spare capacity. This ceiling is the single most important and most frequently omitted part of the method: without a budget on the top category, stakeholders will argue almost everything into it, and the resulting list is a wish list rather than a plan.
Who created MoSCoW and how do I cite it?
Dai Clegg created it in 1994 while working at Oracle, and published it with Richard Barker. Harvard style: Clegg, D. and Barker, R. (1994) Case Method Fast-Track: A RAD Approach. Wokingham: Addison-Wesley. APA style: Clegg, D., & Barker, R. (1994). Case method fast-track: A RAD approach. Addison-Wesley. The 60% effort ceiling and the agile context come from the DSDM Agile Project Framework rather than the 1994 book, so cite the Agile Business Consortium for those.
What is the difference between MoSCoW and RICE?
MoSCoW sorts into four unordered tiers; RICE produces a single ranked list with a number behind each row. MoSCoW answers what ships before a fixed date, RICE answers what to build first. MoSCoW takes an afternoon and needs no data; RICE needs reach, impact, confidence and effort estimates for every candidate. They combine well in that order: rank with RICE, then apply MoSCoW to decide where the line falls for this particular release.
Does MoSCoW work without a deadline?
Not really. Every category is defined relative to one specific timebox, and Won’t have this time is meaningless if there is no this time. In continuous-flow environments with no fixed release date, the four tiers collapse into vague importance labels and the method loses the constraint that makes it useful. A flow-based approach such as Kanban is a better fit for that situation.
Why does everything become a Must Have?
Because nothing stops it. Asking stakeholders to label their own requirements, with no constraint attached, has a predictable equilibrium in which every item is critical. This is the reason DSDM attached an effort ceiling to the top category. Treat Must Have as a budget of roughly 60% of effort, so that adding one item requires removing another, and apply a single consistent test: is there a workaround, however ugly? If there is, it is not a Must.
Deep Resources
Frameworks related to MoSCoW Prioritization
- RICE ScoreA quantitative scoring system that helps product teams prioritize features by evaluating…
- Priority MatrixThe classic Eisenhower-style urgent vs important matrix adapted for feature prioritization,…