MoSCoW prioritization

Origin

Dai Clegg, with Richard Barker, at Oracle; adopted by DSDM, 1994

Level

201 · Tool

Fits

Startup, Small and mid-size, Scale-up

Time to apply

Half a day to sort one release's backlog; a shorter pass each time the deadline or scope changes

What you need

a deadline or release date that will not move · a full list of the requirements someone is asking for · one person with the authority to write Won't have and make it stick

MoSCoW prioritization is a method that sorts a list of requirements into four labeled groups (Must have, Should have, Could have and Won’t have this time) so a team can agree in advance what a fixed deadline and a fixed budget will produce. It answers one question before work starts: what does this release need to be worth shipping, and what can wait for the next one.

Dai Clegg built the method at Oracle in 1994, while working on rapid application development projects that ran against deadlines nobody could move. Secondary accounts consistently tie it to Case Method Fast-Track: A RAD Approach, the 1994 Addison-Wesley book he wrote with Richard Barker. The Dynamic Systems Development Method, now run by the Agile Business Consortium, adopted MoSCoW as one of its core techniques soon after, and the Consortium’s DSDM Project Framework Handbook remains the primary working account of how the four categories are meant to behave.

What each category means

Must have is the smallest set of requirements a release cannot ship without. DSDM’s handbook calls it the “Minimum Usable SubseT” of requirements the project guarantees to deliver. Should have covers work that matters and would be painful to leave out, but the release is still viable without it. Could have is the wish list, wanted but less important, and it doubles as the project’s contingency pool: work pulled in only if time and budget allow. Won’t have this time is the list of items the team has agreed, in writing, will not happen in this release, which is a different thing from an item nobody ever discussed.

DSDM gives a direct test for the Must have column: ask what happens if this requirement is not met. If the answer is cancel the release, since there is no point shipping a solution that misses it, the item belongs in Must have. A second version of the same question works well with a room full of stakeholders: if there is a problem with a Must have item the night before deployment, would the team stop the deployment? A straight “yes” confirms it. Anything the team would ship around, however reluctantly, does not belong in the column.

Why the categories depend on a fixed deadline

MoSCoW only does useful work once a deadline and a budget are fixed. DSDM applies the four categories at three levels at once: across the whole project, inside a project increment, and inside the current timebox (a short, fixed period of work ending on a fixed date). A requirement that is Should have at the project level often becomes Won’t have inside this week’s timebox, because the timebox holds far less time than the whole project does. The categories describe what fits inside the time and money on hand. How much anyone wants a given feature does not enter into it.

Capping Must have at 60% of effort

DSDM’s handbook puts a number on the discipline that stops Must have from swallowing the whole list. On a typical project, Must have requirements should take up no more than 60% of the total effort available, with Could have kept as the main pool of contingency, typically around 20% of effort. That cap counts effort, and it ignores how many items happen to sit in the column. A plan with 95% of its effort locked into Must have has no room left to absorb an estimate that runs long or a bug nobody planned for, and it turns Should have and Could have into items the team will never reach.

Where MoSCoW breaks down

One failure is a skipped test: teams write the four labels down without asking DSDM’s question (what happens if this is missing?) of every item on the list. A 2024 study of the method in software development, run by Vijayakumar, Prasad K and Holla, walked 172 respondents through a hands-on prioritization exercise and asked what went wrong. Confusion was the most frequent complaint, raised by 83 of them, and a separate group named the exact pattern the 60% cap exists to block: too many items landing in Must have. The same paper names a structural gap directly, describing MoSCoW as “devoid of explicit standards or directives for judging the significance and immediacy of requirements.” It also points to an earlier case study, a library system project, where too many items marked must have caused the very delay MoSCoW was meant to prevent.

That gap matters because MoSCoW only separates categories from each other. It does not rank two items inside the same Must have column, and it does not weigh how much more valuable one item is than another, only whether it clears the bar. A team stuck choosing between two items that both pass the Must have test is on its own.

MoSCoW compared with RICE, Kano and the Eisenhower matrix

MoSCoW is one of several ways teams decide what to build first, and it is easy to confuse with tools that answer a different question.

RICE, built by Sean McBride at Intercom, scores each idea as Reach multiplied by Impact multiplied by Confidence, divided by Effort, which gives a ranked list instead of four buckets. That solves the exact problem MoSCoW does not: ranking items against each other. The Kano model, published by Noriaki Kano and three co-authors in 1984, asks a different question again (whether a feature merely functions or goes further and delights) which MoSCoW’s plain necessity test was never built to capture. The Eisenhower matrix looks similar on the surface (four labeled quadrants) but it sorts a person’s own tasks by urgency and importance instead of a team’s shared release against a shared deadline. Reach for the Eisenhower matrix when the problem is one person’s calendar, and reach for MoSCoW when the problem is what a whole team ships by a date that will not move.

Sorting a backlog this way is the same discipline behind Pushers’ work building operational systems: a deadline only holds if everyone agrees, before the work starts, what it has to deliver.

How to apply MoSCoW prioritization, step by step

1. List every requirement in one place. Pull every requirement, feature or fix someone has asked for into a single list, in the exact words the person asking used, rather than a department's summary of it. A scattered set of requests in email, chat and old tickets cannot be prioritized as a group. Result: one list everyone is arguing about, instead of several partial ones.
2. Run the Must have test on each item. For each item, ask what happens if it is not delivered. If the answer is that the release fails or breaks a rule the business cannot break, it is Must have. If the team would still ship without it, it is not. Result: a Must have column that only holds items nobody would ship around.
3. Sort what is left into Should and Could. Should have is important work that is painful to skip, but the release still works without it. Could have is the wish list, useful if time allows, and doubles as contingency. Result: two columns that separate what matters from nice to have.
4. Write Won't have down, in the open. State explicitly which requirements will not happen this time, and say so to the people who asked for them. An item nobody actively sorted simply gets forgotten, and it tends to resurface as a surprise later. Result: a scope boundary the whole team has seen, rather than only the person who wrote it.
5. Add up the effort inside each bucket. Estimate the effort behind every item and total it by category. If Must have effort runs past roughly 60% of what the timebox can absorb, some items do not belong there, or the deadline itself needs to move. Result: a Must have list sized to the time available rather than to people's hopes for it.
6. Timebox it and revisit when the timebox changes. Lock the categories to this release's fixed period. When the deadline, the team or the scope changes, run the sort again rather than patching the old one. Result: a list that stays accurate instead of drifting stale the first week after it was written.

Examples

A fintech's payment feature launch

Illustrative: a cross-border payments company adds a new payout option ahead of a launch date fixed by a partner integration. The identity checks and sanctions screening the payout flow needs are Must have, because a release that skips them breaks the law the payout has to follow. A saved-payee list for repeat transfers is Should have: it makes repeat transfers easier, and dropping it leaves the launch date and the law untouched. A custom notification sound for a completed payout is Could have.

A clinic website rebuild

Illustrative: a physical therapy clinic rebuilds its site before the insurance open-enrollment window opens. Online booking and an intake form that meets the clinic's data-handling obligations are Must have, since patients need to book and the clinic cannot legally collect health details through an unprotected form. A staff bio page is Should have. A blog redesign is Could have, and gets dropped the moment the timebox runs tight.

When to use it

Use MoSCoW once a release has a deadline and a budget that will not move, and a list of requirements longer than the time available to build them. It works best in short, repeatable cycles (a sprint, a release, a regulated launch) where the team needs a shared, written answer to what ships this time rather than an ongoing debate about what matters most in general.

When not to use it

Skip it when there is no fixed deadline forcing trade-offs, since the categories lose their pressure and everything drifts toward Must have. It also does not rank two items inside the same category against each other, so when the hard question is which of two Must haves goes first, pair MoSCoW with a scoring method such as RICE instead of asking the four letters to answer something they were not built for.

Common mistakes

• Letting Must have grow past the point a single deadline can absorb, so the label stops meaning essential and starts meaning everything someone insisted on.
• Running the sort without a fixed deadline attached, which removes the pressure that makes any item Should have or Could have instead of Must have.
• Treating Won't have as a leftover category instead of a decision, so items nobody sorted quietly become promises by default.
• Expecting MoSCoW to rank items inside a category, when it only separates one category from another.
• Sorting once at kickoff and never running it again after the scope or the deadline changes.

FAQ

What does MoSCoW stand for?

MoSCoW stands for Must have, Should have, Could have and Won't have this time. The extra o's exist only to make the acronym pronounceable as a word; they do not stand for anything on their own. Dai Clegg introduced the method at Oracle in 1994, and DSDM adopted it soon after as one of its core techniques.

How do you decide if something is a Must have?

Ask what happens if it is not delivered. DSDM's test: if the answer is to cancel the release, because there is no point shipping without it, the item is Must have. If the team would still ship without it, even reluctantly, it belongs in Should have or lower.

What percentage of a release should be Must have?

DSDM's guidance caps Must have at no more than 60% of the total effort available, with Could have kept as the main contingency pool, typically around 20%. The cap applies to estimated effort. How many items sit on the list is beside the point.

Is MoSCoW the same as the Eisenhower matrix?

No. MoSCoW sorts requirements against a fixed deadline and budget for one release. The Eisenhower matrix sorts tasks by urgency and importance for a person's own time, with no shared release or deadline behind it. Both use four labeled buckets, which is where the resemblance ends.

What is the biggest weakness of MoSCoW?

It gives no way to rank two items inside the same category, and nothing stops Must have from growing past what a deadline can absorb. A 2024 study of the method found confusion and an overloaded Must have column among the most common complaints from people who had just used it.

Sources

1. Agile Business Consortium, DSDM Project Framework Handbook, MoSCoW Prioritisation
2. Agile Business Consortium, What is MoSCoW Prioritization?
3. Dai Clegg and Richard Barker, Case Method Fast-Track: A RAD Approach, Addison-Wesley 1994, Internet Archive record
4. Association for Project Management, How to manage multiple projects (and prioritise like a pro)
5. Vijayakumar, Prasad K and Holla M, Assessing the Effectiveness of MoSCoW Prioritization in Software Development, EAI Endorsed Transactions on Internet of Things, 2024
6. Kravchenko, Bogdanova and Shevgunov, Ranking Requirements Using MoSCoW Methodology in Practice, Springer, Cybernetics Perspectives in Systems, 2022
7. Kano, Seraku, Takahashi and Tsuji, Attractive Quality and Must-Be Quality, Journal of the Japanese Society for Quality Control 14(2), 1984
8. Intercom (Sean McBride), RICE Prioritization Framework for Product Managers
9. ProductPlan, MoSCoW Prioritization
10. ProductPlan, Kano Model
11. Productboard, Product Prioritization Frameworks
12. Aha!, Product Prioritization Frameworks: 12 Common Models
13. TechTarget, What is the MoSCoW method?
14. Smartsheet, All about Project Prioritization
15. Mindtools, The MoSCoW Method
16. US Financial Crimes Enforcement Network, CDD Rule FAQs
17. PRINCE2.com, The MoSCoW method explained
18. IAPM, The MoSCoW method: balancing needs and resources
19. Dwight D. Eisenhower, Address at the Second Assembly of the World Council of Churches, 19 August 1954 (The American Presidency Project)
20. Kurt Matzler and Hans H. Hinterhuber, How to make product development projects more successful by integrating Kano's model of customer satisfaction into quality function deployment, Technovation 18(1), 1998

Last updated Sep 25, 2026

Ilia PushinFounder, Pushers · Co-founder and COO, ARBI ExchangeIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn