MoSCoW Method: Must, Should, Could and Won't Have

Created by Dai Clegg - https://en.wikipedia.org/wiki/MoSCoW_method

Overview

The MoSCoW method is a requirements prioritization technique that places every requirement for a fixed timeframe into one of four categories: Must have, Should have, Could have and Won't have this time. The capital letters name the categories, and the lowercase o's are there only to make the word pronounceable, as the Wikipedia entry on the MoSCoW method notes. The DSDM Agile Project Framework, which holds the most complete definition, calls MoSCoW "a prioritisation technique for helping to understand and manage priorities" (DSDM handbook: MoSCoW prioritisation). Each label is a statement about delivery: Must haves are guaranteed, Should haves are expected, Could haves arrive if time allows, and Won't haves are agreed to be outside this timeframe.

Dai Clegg developed the method in 1994 for use in rapid application development, and it was first used extensively with the dynamic systems development method (DSDM) from 2002, according to Wikipedia. That account cites the book Clegg wrote with Richard Barker, CASE Method Fast-Track: A RAD Approach, which Open Library lists as an Addison-Wesley title from 1994. ProductPlan adds that Clegg created MoSCoW while working at Oracle. The Agile Business Consortium now publishes the DSDM handbook, and its MoSCoW chapter is the reference most practitioners work from for MoSCoW in project management.

The handbook explains why four named categories work better than simpler schemes. A high, medium and low scale is weaker because the definitions are usually missing and because a single middle option "allows for indecision". A numbered sequence deals badly with items of similar importance and invites long arguments about whether an item belongs one place higher or lower. MoSCoW gives each category a meaning the business can hold the team to. A Must have belongs to the Minimum Usable SubseT (MUST): there is no point delivering on the target date without it, or the solution would be illegal, unsafe or not viable.

MoSCoW depends on a fixed deadline. DSDM fixes time, cost and quality and varies the features, so when a timebox runs short, lower-priority requirements are dropped with the business's agreement (DSDM handbook). Should haves and Could haves are therefore the plan's contingency. The handbook recommends typically no more than 60% of the effort on Must haves and a pool of Could haves of around 20% of the effort (DSDM: MoSCoW prioritisation). The Won't haves are excluded when that effort is calculated.

That guideline has been tested. Eduardo Miranda of Carnegie Mellon ran Monte Carlo simulations of the rules and concluded that a team "ought to be able to deliver all Must Have features for underestimations of up to 100% with very high probability" (Moscow Rules: A Quantitative Exposé). In his analysis the 60, 20 and 20 split works as a reserve of 40% for the Must haves and 20% for the Should haves, provided the team does not start a lower category before finishing the higher ones.

The Won't have category does as much work as the Must have. DSDM records Won't haves in the Prioritised Requirements List, where they clarify the scope and keep requirements from being "informally reintroduced at a later date". The same requirement can carry different priorities at three levels (the project, the Project Increment and the Timebox), and at the Timebox level most requirements are Won't have for that Timebox. Turning those levels into a sequence of releases is covered in MoSCoW phased delivery and release planning.

The method has known limits. The Wikipedia entry lists the main criticisms: it does not rank items within a category, it gives no transparent way to decide between Must and Should, and "Won't have" is ambiguous unless the team says whether it means this release or never. ProductPlan adds that results suffer when relevant stakeholders are left out or when the team is biased for or against an initiative. Teams that need an order inside a category often pair MoSCoW with a scoring framework such as RICE or WSJF, which the comparison below covers.

Core Principles

Must have means the Minimum Usable SubseT

A Must have is part of the smallest set of requirements the project guarantees to deliver. The DSDM definition gives four grounds: no point delivering on the target date without it, not legal without it, unsafe without it, or no viable solution without it. Importance alone does not qualify a requirement. If a workaround exists, even a manual and painful one, the requirement is a Should have or a Could have.

Should have is important but survivable

A Should have is "important but not vital". Leaving it out may hurt, and the business may need a workaround such as managing expectations, accepting some inefficiency, or using an existing solution or paperwork. The solution is still viable without it. The handbook says the business can reasonably expect Should haves to be met along with the Musts, while Could haves are delivered in full only in a best case. The handbook separates the two by the degree of pain a missing requirement causes, measured in business value or the number of people affected.

Could haves are the first contingency

Could haves are wanted or desirable but have less impact if left out than a Should have. The DSDM handbook calls them the main pool of contingency: when a deadline is at risk, one or more Could haves are the first choice to drop. A plan that contains no Could haves has no cheap place to absorb a bad estimate.

Won't have this time is a recorded decision

Won't haves are requirements the team has agreed will not be delivered in this timeframe. They stay on the requirements list, where they clarify scope, stop the same request coming back informally, and tell stakeholders plainly that some things will not make it this time. Because the category is scoped to a timeframe, a Won't have can return as a higher priority in a later increment.

Fix the deadline and flex the features

MoSCoW is built for a fixed timeframe. In a traditional project, the handbook notes, every requirement is treated as a Must have and the end date slips when problems appear. A fixed timebox forces the choice about what to drop, and the categories decide that choice in advance. Without a timebox there is nothing to trade against, and every item drifts toward Must.

Keep the Must haves to what the team can guarantee

DSDM recommends that Must haves take no more than 60% of the effort, and says higher levels introduce a risk of failure unless estimates are accurate, the approach is well understood, the team is performing and the environment is low-risk (DSDM handbook). The exact split is for each team to agree. What cannot change is that some visible flexibility remains below the Must line.

Decompose before you argue

When every requirement appears to be a Must have, the handbook reads it as a sign that the requirements have not been broken down far enough. A high-level requirement usually splits into parts with different priorities, and the less important parts can then be dropped to protect the deadline. Acceptance criteria can carry their own priorities as well, so a single requirement can have a Must threshold and a Should target.

Steps

1. Fix the timeframe and the objective Confirm the deadline, the team and the budget for the project, increment or timebox you are prioritizing. Write down the business objective the delivery must serve, because DSDM advises tying each requirement to a project objective. A requirement linked to an objective that is not itself a Must is probably not a Must either. If the date or the team is still open, settle that first, since the categories only mean something against a fixed constraint.

2. Agree the rules before capturing requirements Share the DSDM definitions of the four categories and agree who explains a proposed Must, which DSDM assigns to the Business Visionary or an empowered Business Ambassador. The line between Should and Could is the subjective one, so agree objective criteria for it up front, for example the number of people affected or the value of benefits at stake. Agree an escalation path for disputes as well. The handbook suggests reaching this agreement before the requirements are captured, when nobody is yet defending a particular item.

3. Start every requirement at Won't have One of the handbook's tips is to begin with all requirements as Won't haves and make each one earn a higher category. Collect the candidates from the backlog, stakeholder requests, research findings and known technical work into one list at a size the team can estimate. Break large requirements into parts before prioritizing them. Keep the wording neutral so the item's owner cannot win by description alone.

4. Test every proposed Must have Ask the handbook's question for each candidate: what happens if this requirement is not met? If the answer is to cancel the project, it is a Must; otherwise it is a Should or Could. Ask the second test too: if the team said the night before deployment that it could not deliver this, would you stop the deployment? Check for a workaround and for dependencies, because a Must cannot depend on anything other than a Must.

5. Check the effort balance Estimate the effort for each category and compare the Must total with the capacity of the timeframe. The DSDM guideline is typically no more than 60% Must effort and around 20% Could effort. If the Must share is too high, decompose and re-test the Musts, or change the timeframe. Leave the Won't haves out of the calculation.

6. Record the list, including the Won't haves Publish the output of the MoSCoW analysis: every requirement, its category and the reasoning for any borderline call. Keep the Won't haves on it, since that is what makes the scope boundary visible. Where priorities differ between the project, the increment and the timebox, record each level separately rather than overwriting one with another. Share the list with everyone who will be asked to accept the result.

7. Deliver Musts first and drop Coulds first Work through the Must haves before starting lower categories. Miranda's analysis of the rules assumes exactly this order, and the reserve it measures disappears if the team spreads effort across all categories (Moscow Rules). When estimates prove wrong, drop Could haves first and then Should haves, with the business's agreement. Track how many Shoulds and Coulds each timebox delivers, since that figure is the earliest warning that the plan is too full.

8. Re-prioritize at each boundary Review the priorities of unfinished requirements at least at the end of each timebox and each increment, as the handbook recommends. Re-prioritize everything not delivered against the needs of the next increment: a Could have may become a Won't have, and a Won't have may become a Must. When new work appears mid-timebox, classify it with the same rules and check that it does not push the Must share past the agreed level.

When to Use

• A delivery date is fixed by a contract, a regulation or a launch event, and you need to agree in advance what will be dropped if the work runs long.
• Business and technical stakeholders must agree scope together, and plain-language categories will be understood faster than a scoring formula.
• You are setting the boundary of a first release, where the Must haves define the smallest version worth shipping.
• Requests keep returning after they were declined, and a recorded Won't have list would settle them.
• The requirements include legal, safety or contractual obligations that must be separated from improvements.

When Not to Use

• There is no fixed timeframe or capacity. The categories have nothing to trade against and most items end up as Musts.
• You need a strict order within a long backlog. MoSCoW does not rank items inside a category, so a scoring method such as RICE or WSJF fits better.
• One person will decide regardless of the discussion. The method's value comes from shared, recorded agreement, and an overruled list loses its authority.
• The work is a stream of small experiments with no shared deadline, where a fast scoring model such as ICE is lighter to run.

MoSCoW Compared with Scoring Frameworks

MoSCoW decides what is in or out of a timeframe. Scoring frameworks decide the order of items. The rows below summarize each approach from its own source.

The approaches combine well. One pattern is to use MoSCoW to draw the scope line with stakeholders and a scoring model to order work inside the Should and Could categories. Intercom itself says RICE scores "shouldn't be used as a hard and fast rule", which leaves room for a category decision to override a score. The RICE framework page covers that model in depth.