MoSCoW is a prioritization method that sorts backlog items into four categories instead of one ranked list: Must have, Should have, Could have, and Will not have this time. It was developed in the 1990s for software requirements gathering and has stayed popular because it is fast to explain, easy for non-technical stakeholders to participate in, and forces an explicit conversation about what is being deliberately excluded, not just what is included.
What changed in 2026
- The category names got stricter definitions in practice. More teams now write down what "must" means for a specific release (usually: the release fails, functionally or legally, without it) rather than relying on a shared intuition that turns out not to be shared at all.
- MoSCoW increasingly pairs with a numeric method. Teams use MoSCoW to scope a release, then RICE or a value score to order items within the Should and Could buckets, rather than treating MoSCoW as sufficient on its own.
- AI backlog tools default to MoSCoW tags for quick triage. Because the categories map to simple labels, several backlog and roadmap tools now auto-suggest a MoSCoW tag from a ticket description as a first-pass sort.
The four categories
| Category |
Meaning |
Rule of thumb |
| Must have |
Release fails without it, functionally or legally |
Keep to well under half the release |
| Should have |
Important, but the release can ship without it |
The bulk of active negotiation happens here |
| Could have |
Desirable, low cost if included, first to cut |
Nice-to-have polish and small extras |
| Will not have this time |
Explicitly out of scope for this release |
Written down to stop repeat re-pitching |
The "this time" in the fourth category matters. It is not a permanent rejection, it is a statement that the idea is not happening in the current release, which makes it much easier for a stakeholder to accept than an outright no.
Why Must have keeps growing, and how to stop it
The single most common failure mode of MoSCoW is category drift: every stakeholder believes their item is a must have, so the must-have bucket grows until it is most of the backlog and the method has stopped sorting anything. The fix is a strict, written test applied before an item is tagged must have, usually some version of "does the release fail, functionally or legally, without this," and a hard cap, often expressed as a percentage of total scope, that forces genuine tradeoffs rather than a wish list with a label on it.
Using MoSCoW alongside a numeric score
MoSCoW answers a scoping question — what belongs in this release — but it does not answer a sequencing question inside a category. Two items can both be Should Have and still need an order. This is where a numeric method like RICE or a simple value-vs-effort score earns its keep: use MoSCoW to draw the release boundary, then a score to order what falls inside it. Treating MoSCoW as the entire backlog prioritization system, rather than one layer of it, is the most common way teams outgrow it.
When MoSCoW is the wrong tool
MoSCoW works best when there is a fixed release or deadline to scope against. It works poorly for an open-ended, continuously delivered backlog with no natural release boundary — in that setting, a numeric ranking method that produces an ordered list is usually more useful than four buckets with no internal order.
FAQ
Who decides what counts as a must have?
Ideally a single accountable person, usually the Product Owner, after input from stakeholders, not a group vote, which tends to inflate the must-have category as everyone defends their own item.
Is MoSCoW still relevant with numeric scoring methods available?
Yes, for a different job. MoSCoW is fast, plain-language, and easy for non-technical stakeholders to use for scoping. Numeric methods are better for fine-grained sequencing. Many teams use both.
What percentage of a release should be must have?
No fixed number, but if must have exceeds half the release, the category has likely drifted and needs re-scoping with a stricter test.
Does Will not have mean never?
No, it means not in this release. Items can and do return in a future round; writing them down explicitly just prevents them from being re-argued every single planning cycle.
Where to go next