MoSCoW Method: Prioritize Without Making Everything a Must

The MoSCoW method sorts requirements into four commitments: Must Have, Should Have, Could Have, and Won't Have this time. It works best when a team has one deadline, limited capacity and a real need to agree what gives way when the plan changes.

The labels are easy. The difficult part is making them mean something. If everything is a Must Have, the team has described its wish list, not prioritized it.

This guide shows how to run a useful MoSCoW analysis. It covers the tests for each category, a worked software development example and the failure modes that make the method look simpler than it is.

What is the MoSCoW method?

MoSCoW is a prioritization technique for reaching agreement about which requirements a particular release or timebox will include. The name is built from the four categories:

The lowercase letters only make the acronym pronounceable. MoSCoW is also called the MoSCoW framework, MoSCoW prioritization, MoSCoW analysis, or the MoSCoW technique. These names describe the same method.

Software development teams often use MoSCoW during release planning, MVP definition, requirements prioritization and stakeholder workshops. It can also work outside Agile, as long as everyone is prioritizing the same scope and timeframe.

Where MoSCoW came from

Dai Clegg developed the method at Oracle in 1994. It later became part of the Dynamic Systems Development Method, or DSDM.

That origin matters because MoSCoW was designed for projects that fix time and cost while negotiating scope. A Could Have is not a polite synonym for low priority. It is planned contingency. If delivery runs into trouble, the team already knows what can leave the release without destroying the minimum usable outcome.

The Agile Business Consortium describes the original DSDM rules in more detail. Its Must Have test is strict: if a viable workaround exists, even a painful manual one, the requirement probably belongs in Should Have or Could Have.

The four categories, with tests that force a decision

Must Have

A Must Have is non-negotiable for the chosen release. At least one of these statements should be true:

• The release has no usable outcome without it
• Shipping without it would be illegal or unsafe
• A signed commitment makes it mandatory for this deadline
• Another Must Have cannot work without it

Ask: What happens if we leave this out of this release?

If the honest answer is "users will be annoyed" or "Sales really wants it," it is not automatically a Must Have. If a workaround exists and the release remains viable, test it as a Should Have.

Should Have

A Should Have matters, but the release can survive without it. The missing requirement creates real pain, cost or inconvenience, yet there is a temporary workaround.

For example, CSV export may be important for enterprise reporting. If the team can provide an API export manually for one release, CSV export may be a Should Have rather than a Must Have.

The useful question is: How painful is the workaround, for whom, and for how long?

Could Have

A Could Have adds value if capacity remains. Leaving it out has a smaller effect than leaving out a Should Have.

Could Haves protect the deadline. They are the first planned candidates to move when estimates grow, a dependency slips or a Must Have turns out to be harder than expected.

Do not fill this category with ideas nobody wants. A good Could Have still creates value. It simply does not deserve capacity before the current Must and Should commitments.

Won't Have this time

Won't Have is an explicit scope decision, not a graveyard. Write down the item, the reason and the timeframe.

"Native mobile app: Won't Have for Q4 because responsive web covers the launch workflow. Revisit after mobile usage reaches 20%." is useful.

"Mobile later" is not. It leaves stakeholders free to assume the item might quietly return next week.

A worked MoSCoW prioritization example

Imagine a B2B SaaS team preparing a Q4 enterprise release. The deadline is fixed because two customers need the release before renewal. Engineering estimates 40 days of capacity.

The initial shortlist looks like this:

At first, Sales marks CSV export as Must Have. Customer Success marks dark mode as Should Have because the vote count is high. The categories only become useful when the group examines the consequences:

• CSV export has a painful workaround, so the release can remain viable without it
• Dark mode has broad demand, but the segment data shows little enterprise relevance for this particular release
• SSO, permissions and audit export connect to concrete renewal and contractual outcomes

The result is not a universal ranking of every idea. It is an agreed scope for one Q4 release.

How to run a useful MoSCoW session

Step 1: Choose one release and one deadline

MoSCoW categories are relative to a timeframe. A capability can be Must Have for the annual product commitment and Won't Have for this month's release.

Write down:

• the release or timebox
• the outcome it must create
• the deadline
• the available capacity
• who approves the final scope

Without that boundary, people classify ideas according to their general importance and every strategic initiative becomes a Must Have.

Step 2: Write the category rules before reviewing ideas

Agree what qualifies as a Must Have and which workarounds are acceptable. Also decide how the team will resolve disagreement.

For the Q4 example, the team might use these rules:

• Must Have: contractual, legal, safety or minimum usable outcome
• Should Have: material enterprise value with a workable temporary alternative
• Could Have: useful value that can move without threatening the release outcome
• Won't Have: deliberately outside Q4, with a revisit condition when needed

This is also the point to decide whether you measure the category balance by item count or effort. Effort is usually more honest. One large Must Have can consume more capacity than ten small Could Haves.

Step 3: Bring the shortlist and evidence together

Do not categorize titles in isolation. Add the problem, affected users, votes, customer segment, revenue context, delivery estimate and known dependencies.

In ProductLift, open the prioritization module and filter the requests for the release you are planning. The request, voters, account information and internal discussion remain visible while the team classifies it. This is the moment the product belongs in the process, because the team now needs evidence beside the candidates.

If you are not ready to use a live backlog, download the MoSCoW Excel template and add one row per requirement with a rationale column.

Step 4: Let people classify independently first

Ask Product, Engineering, Sales and Customer Success to assign categories before the meeting. Independent input exposes real disagreement. A group discussion that starts with one senior opinion often creates artificial consensus.

For a small workshop, collect the categories in the spreadsheet. For a recurring team process, use MoSCoW inside ProductLift to invite participants, save drafts and compare the submitted categories during review.

Step 5: Discuss the disagreements, not every row

Start with items where categories differ. Ask each participant which evidence or consequence caused the choice.

Useful questions include:

1. Does the release still achieve its outcome without this item?
2. Is there a workaround, and who absorbs its cost?
3. Which customer segment is affected?
4. Is the deadline genuinely fixed?
5. What would we remove if this becomes a Must Have?

That final question is especially effective. A new Must Have is not free. It either consumes contingency or pushes another commitment out.

Step 6: Check Must Have capacity and approve the scope

DSDM guidance commonly limits Must Have work to about 60% of available effort. This leaves space for Should and Could work plus delivery uncertainty. Treat it as a warning threshold, not a mathematical law.

If Must Haves consume nearly all capacity, one of three things is true:

• the deadline is not realistic
• the minimum usable outcome is still too broad
• the team is using Must Have to avoid a difficult stakeholder conversation

Record the final category and rationale. Then move the approved work into delivery. In ProductLift, the same request can move to the roadmap, connect to Jira or Azure DevOps and notify voters as its status changes. The MoSCoW decision does not have to disappear into a workshop file.

Common MoSCoW mistakes

Everything becomes a Must Have

This is the classic failure. Fix it by requiring a consequence test and forcing every proposed Must Have to name what leaves the release in exchange.

The team mixes several timeframes

"Essential for the product" and "essential for this release" are different claims. Put the timeframe in the category label if needed: Must for Q4, Should for the annual plan.

Categories replace evidence

MoSCoW does not tell you which customer problem matters most. Bring demand, segment, revenue, strategy and delivery evidence into the discussion.

The team ranks inside a category by instinct

MoSCoW groups requirements but does not order items inside Must or Should. If you need a numeric sequence, use RICE when reach data is available. Use ICE for a faster relative score, or an Impact Effort matrix for a visual tradeoff.

Won't Have means never

The complete category is Won't Have this time. Add a reason or revisit condition so the decision stays clear without pretending the idea can never become relevant.

When MoSCoW is the right framework

Use MoSCoW when:

• a release, project or timebox has a real deadline
• stakeholders need plain-language categories
• the team must define a minimum usable scope
• contingency needs to be visible before delivery begins
• the main question is what is in or out, not the exact rank of 100 ideas

Choose another method when:

• you need a strict numeric order across a large backlog
• the candidates affect very different numbers of users
• cost of delay and job duration drive the decision
• customer satisfaction is the main unknown
• there is no shared outcome or timeframe yet

The prioritization framework comparison runs MoSCoW, RICE, ICE and other methods against the same decision criteria.

Run the same backlog through MoSCoW

Use the format that fits the next task:

• Classify several requirements in the free MoSCoW calculator
• Download the MoSCoW Excel template for an offline workshop
• Apply MoSCoW to live customer requests in ProductLift when votes, segments, team input and delivery need to stay connected
• Explore the complete prioritization module if your team also uses RICE, ICE, Impact Effort or custom scoring

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 letters make the acronym pronounceable.

Is MoSCoW an Agile framework?

MoSCoW is a prioritization technique used in DSDM and many Agile teams. It is not a complete delivery framework by itself. Scrum, Kanban and other teams can use it for release or timebox scope.

What is the difference between Should Have and Could Have?

A Should Have creates material pain when omitted, but a workaround keeps the release viable. A Could Have creates useful value but has a smaller consequence if it moves to a later release.

What percentage should be Must Have?

DSDM guidance often uses about 60% of effort as the upper target for Must Have work. The exact percentage is less important than preserving real contingency and refusing to label nearly the entire release as mandatory.

Can MoSCoW rank items inside a category?

No. MoSCoW classifies scope. Use a second method such as RICE, ICE, weighted scoring or Impact Effort if the team needs a strict order within one category.