The MoSCoW Method for Prioritizing Requirements

Contributor
Apr 6
6 min read

MoSCoW is the prioritization method that almost works in every project meeting. Must have, Should have, Could have, Won't have — four buckets, easy to explain, instantly usable. The trouble is that without discipline, every requirement migrates to Must, and the framework collapses to "list of features." Used well, it forces the trade-offs the team needs to make. This guide is how to use it well.

The Four Categories

Must have. Non-negotiable for the release. If this isn't done, the release is a failure. The product doesn't ship without it, the user can't complete the core flow, the regulatory deadline isn't met.

Should have. Important but not critical for this release. The release could ship without it, but the product is meaningfully weaker. Plan to include unless time forces a cut.

Could have. Desirable, lower priority. Nice-to-have. If time and capacity permit, do it. If not, drop without anguish.

Won't have (this time). Explicitly out of scope for this release. Not "rejected forever" — "not this round." Naming it prevents the requirement from leaking back in later.

The deceptively important category is "Won't have." Explicit out-of-scope decisions prevent the slow expansion that kills releases.

What Makes "Must" Actually Must

The most common failure mode is everything ending up in Must. The category becomes meaningless when it includes 80% of the backlog.

A working test: if you ship without this, does the release fail? Not "is it important," not "would the user want it" — does the release fail?

For most products, the answer for any single feature is no. The product can ship without most things. What's actually Must is usually a small core:

The user can complete the primary value-producing action
The system doesn't lose data
The system meets the legal or regulatory bar
Critical security properties hold
The system doesn't break the things that are already working

That's a short list. Probably 5-15 items for any given release.

Anything else is Should at most. Forcing yourself to be honest about Must is the work.

What Goes in Should

Should is for things that would make the release notably better without being existential. Many features fit here.

The test for Should: if we cut this, the release ships, but we'd want to add it in a follow-up soon. Users would notice the absence.

Should items get serious attention during planning. Most of them will probably ship. But they're not in the same category as Must. The difference matters when capacity is tight.

What Goes in Could

Could items are good ideas that don't justify pushing other things out. They ship if there's room.

The trap with Could: the category becomes a wish-list dumping ground that no one ever returns to. The Could list grows; nothing on it gets done.

To avoid the trap: periodically audit the Could list. Promote items that genuinely deserve attention. Demote or delete items that have been there for months without anyone advocating for them.

What Goes in Won't

Won't is the explicit decision not to include something this round. It's the most undervalued category.

Why it matters: requirements you haven't named are requirements that can resurface mid-release. "We never decided whether to do X" produces fights three weeks in. "We decided X is Won't have this release" produces clean focus.

For the Won't list, be specific about scope. "Won't have payments in this release" is clear. "Won't have payments yet" is squishy and invites debate. Bound it: "Won't have payments in Q3; revisit for Q4."

Running a MoSCoW Session

A workable structure for a 90-minute session:

List the candidates (15 min). All proposed requirements on the table. No prioritization yet.
First pass: silent voting (15 min). Each participant marks each item M/S/C/W independently. Captures initial intuition without group dynamics.
Aggregate (10 min). Where does the group agree? Where do they diverge?
Discuss the divergent ones (40 min). The interesting cases are where people disagree. Talk through why.
Final classification (10 min). Group settles on a category for each item.

The hardest part is keeping Must small. Use a heuristic: "Must has to fit in N items." If you have a target release date, work backward from capacity to set N.

The Time-Box Discipline

MoSCoW works best with a time-boxed release. The framework assumes you're allocating fixed time to variable scope. Without the time box, "Must" expands to fill available time and the prioritization loses meaning.

A working pattern: "We have 8 weeks. What can we Must-have in 4 weeks, leaving 4 weeks for Should and contingency?" The numbers force discipline.

If your context doesn't have time boxes — you ship continuously, with no fixed releases — MoSCoW is less useful. Prioritization in that context is more about ongoing reordering of a backlog than about categorizing into buckets.

The 60/40 Rule of Thumb

A common rule from MoSCoW practitioners: Must should be no more than 60% of estimated effort, leaving 40% for Should, Could, and contingency.

The reasoning: real-world execution always involves surprises. Estimates are wrong. New requirements appear. If 100% of capacity is allocated to Must, anything that goes wrong cascades into Must items getting cut, which means the release fails by definition.

The 60/40 split builds in resilience. Must items are highly likely to ship. Should items have a margin. Could items absorb the variance.

Apply with judgment; the exact numbers vary by context. The principle holds: keep Must below capacity.

What Goes Wrong

A few patterns to watch for.

Must-creep during execution. A Should item is reclassified to Must mid-release because someone advocates for it. Without challenge, this happens repeatedly. By release time, Must is double what was planned.

Could as backlog dump. Items go to Could and stay there forever. The category becomes a graveyard.

No Won't list. Without an explicit out-of-scope, requirements not formally accepted keep coming back. The team relitigates the same decisions weekly.

Stakeholder gaming. Stakeholders learn that Must is what ships, so they label everything Must. Counter by including stakeholders in the prioritization conversation, not just letting them propose.

Treating it as final. A MoSCoW classification from kickoff that's never revisited goes stale. Re-prioritize at milestones.

When MoSCoW Doesn't Fit

MoSCoW assumes:

A discrete release with a fixed scope decision
Stakeholders willing to make trade-offs
A relatively small number of requirements (tens to low hundreds, not thousands)

It's a poor fit for:

Continuous delivery shops with no fixed release boundaries
Backlogs of thousands of items where binary categorization is too coarse
Strict-priority contexts where ranking matters more than buckets

For those contexts, ordered backlogs, weighted scoring, or hybrid approaches work better.

Combining with Other Methods

MoSCoW is at its strongest combined with other techniques.

MoSCoW + estimation. Each Must gets a rough estimate. Sum of Must must fit in 60% of capacity.
MoSCoW + RICE. RICE (Reach, Impact, Confidence, Effort) scores items quantitatively; MoSCoW provides a final bucketing layer for the planning conversation.
MoSCoW + Kano. Kano model categorizes by user satisfaction impact; MoSCoW categorizes by release inclusion.

Use other tools to develop the priorities; use MoSCoW to communicate the decisions.

A Worked Example

A team is planning a 6-week release for a new dashboard feature.

Must have:

Users can view a list of dashboards they have access to
Users can open a dashboard and see its data
Permissions are enforced
Loading time under 3 seconds for typical dashboards

Should have:

Search/filter on dashboard list
Ability to favorite dashboards
Recent dashboards section
Mobile-responsive layout

Could have:

Custom dashboard sorting
Bulk export
Sharing via email
Dark mode

Won't have (this release):

Dashboard editing in the new UI (separate effort)
Collaboration features
Real-time updates (next quarter)
Comments on dashboards

Now the team has a clear picture. Must fits in 3-4 weeks of work. Should fits in another 1-2. Could is optional. Won't is bounded and explicit.

Key Takeaway

MoSCoW splits requirements into Must, Should, Could, and Won't. The framework works when Must is small (5-15 items, fitting in ~60% of capacity), when Won't is named explicitly, and when classifications get revisited as the release progresses. The most common failure is Must expanding to include everything; the fix is the discipline of asking "does the release fail without this?" Combine with estimation and time-boxing to make the prioritization actionable. MoSCoW is a planning tool, not an estimating tool — use it to communicate priorities, not to compute them.

ShiftQuality