MoSCoW Prioritisation Explained

MoSCoW is one of the simplest prioritisation techniques available and one of the most commonly misapplied. Teams sort work into four categories, feel organised, and discover at release time that everything was labelled Must.

The framework has one rule that makes it work, and it is the rule people skip.

This guide explains the four categories, how to run a session, the capacity rule that gives the method its value, and how it compares to scoring frameworks.

Quick answer: Quick answer: MoSCoW sorts requirements into four categories — Must have, Should have, Could have, and Won't have this time. Must haves are non-negotiable for the release; Should haves are important but survivable; Could haves are included only if capacity allows; Won't haves are explicitly excluded. The rule that makes it work is capping Must haves at well under total capacity, commonly around 60 percent, leaving room to absorb the unexpected.

What MoSCoW Stands For

The four letters represent Must have, Should have, Could have and Won't have this time — categories describing necessity for a specific release rather than general importance.

Must have: the release fails without it

A Must have is something whose absence means the release is not viable. Not disappointing — not viable.

The test is direct: if this is missing, do we still ship? If the honest answer is yes, it is not a Must.

Legal requirements, core functionality without which the product does nothing, and safety-critical items qualify. Very little else does.

Should have: painful to omit, not fatal

Important, with real impact if left out, but the release still works and the omission can be lived with temporarily.

Should haves are usually the largest group. They are also where the most useful conversation happens, because deciding something is a Should rather than a Must is where scope negotiation actually occurs.

Could have: included if there is room

Desirable, small impact if omitted. These are the first things dropped when the timebox tightens, and everyone has agreed that in advance.

Having an explicit Could layer is valuable precisely because it gives you something planned to sacrifice rather than making the decision under pressure.

Won't have this time: explicitly excluded

Agreed to be out of scope for this release. The phrase "this time" matters — it signals deferral rather than rejection, which makes the conversation with stakeholders considerably easier.

This category is the one most often omitted, and omitting it means those items linger ambiguously, resurfacing repeatedly.

Related: Scrum Roles Explained: PO, Scrum Master, Dev Team

MoSCoW Categories Compared

Category Test Typical share of effort If omitted Negotiable?

Must have Release fails without it ~60% No release No Should have Painful but survivable ~20% Workaround needed Under pressure Could have Nice to have ~20% Barely noticed Yes, first to go Won't have this time Agreed out of scope 0% Not in this release Already decided

Related: How to Do Sprint Capacity Planning

How to Run a MoSCoW Session

Define what "must" is measured against, categorise everything, challenge every Must, cap the Musts at a share of capacity, and record the Won'ts explicitly.

Define what "must" is measured against

Must have for what? A specific release, a specific date, a specific objective. Without that anchor the categorisation is meaningless, because everything is a Must for something eventually.

State it in one sentence at the start of the session and put it where everyone can see it.

Categorise, then challenge every Must

First pass: sort everything quickly. Second pass: go through each Must and ask what happens if it is not there.

The second pass is where the work happens. Roughly half of initial Musts do not survive a direct challenge, because people categorise by importance rather than by necessity on first attempt.

Cap the Musts at a share of capacity

Estimate the effort in each category. If Musts exceed about 60 percent of available capacity, you have not finished prioritising.

This is the step that converts MoSCoW from labelling into a decision. Without the cap, the categories are just adjectives.

Record the Won'ts explicitly

Write down what is out of scope and share it. Stakeholders should be able to see their request was considered and deferred rather than ignored.

This prevents the same items returning every planning session, and it is a large part of why the framework works well with non-technical stakeholders.

Related: How to Reduce Cycle Time on Your Team

The Rule That Makes MoSCoW Work

Must haves should consume well under total capacity — commonly around 60 percent — because the remaining buffer is what allows the release to survive the unexpected.

Musts should be well under total capacity

If Musts consume 95 percent of capacity, one problem sinks the release. If they consume 60 percent, you have 40 percent of planned-but-sacrificeable work as contingency.

The Shoulds and Coulds are not just lower priorities. They are the buffer, and they are designed to be dropped.

Why the buffer is the whole point

Every release encounters something unexpected — a technical problem, an absence, a change in requirements. The question is whether that consumes contingency or breaks the commitment.

With a proper cap it consumes Coulds. Without one it consumes the delivery date, which is the outcome the framework exists to prevent.

What happens without the cap

Everything becomes a Must, the release is fully committed from day one, and the first difficulty produces either a missed date or an all-hands push.

Teams in this position typically conclude MoSCoW does not work. What did not work was categorisation without the capacity rule.

Related: Definition of Done: Examples From Real Teams

Where MoSCoW Fails

MoSCoW breaks down when every item becomes a Must, when it is used as a permanent backlog structure, or when nobody has authority to settle disagreements.

When everything becomes a Must

The commonest failure. Stakeholders learn that Must is the label that gets delivered, so everything arrives labelled Must.

The defence is the capacity cap plus the challenge pass. If Musts exceed the cap, the session is not finished, and that is a factual statement rather than a negotiation.

When it is used as a permanent backlog structure

MoSCoW describes a specific release or timebox. Applied as a permanent property of backlog items, the labels drift out of meaning — something that was a Could for the last release may be a Must for the next.

Re-categorise per release rather than treating the label as an attribute of the item.

When nobody owns the decision

If categorisation is by committee with no final decision-maker, disputes end in everything being upgraded.

Name the person who decides before the session. Their role is not to overrule everyone but to settle the cases where reasonable people disagree.

MoSCoW Versus Other Prioritisation Methods

MoSCoW suits fixed-timebox releases with stakeholders; scoring frameworks like RICE suit ranking a long backlog by expected value; simple ordering suits small teams.

Against RICE and weighted scoring

RICE produces a ranked list by estimating reach, impact, confidence and effort. It is better for comparing many items of similar type.

MoSCoW is better for scoping a release against a fixed date with stakeholders in the room, because the categories are intuitive to non-technical people in a way that a composite score is not.

Against simple ordering

An ordered backlog is more precise — it forces a decision between every pair of items.

MoSCoW is coarser but faster and easier to agree in a group.

Many teams use both: MoSCoW to agree release scope with stakeholders, ordering within the Musts to sequence the work.

When to use which

Use MoSCoW for fixed-date releases and stakeholder negotiation. Use RICE or weighted scoring for continuous backlog ranking. Use simple ordering when the team is small and the list is short.