MoSCoW Prioritization

Origins

MoSCoW was introduced by Dai Clegg at Oracle in 1994 as part of his work on Rapid Application Development¹. The technique became a defining feature of the Dynamic Systems Development Method (DSDM), which adopted it as a core practice for scope management within fixed-time and fixed-cost projects. From DSDM it spread widely — into Scrum teams, business analysis, requirements engineering, and general product prioritization.

The acronym — Must, Should, Could, Won't — is sometimes spelled MoSCoW with the lowercase "o"s as silent ornament, just to make it pronounceable. The lowercase letters carry no meaning.

The Four Buckets

Must Have

Non-negotiable. The product, release, or sprint cannot be considered successful without these. Legal requirements, safety-critical features, essential capability that defines the offering — these are Musts. The test: would we cancel the release if this didn't ship? If yes, it's a Must. If no, it isn't.

Should Have

Important but not vital. The team would ship without them under duress, but doing so leaves a meaningful gap. Often these are the features that turn an acceptable product into a desirable one — not the floor, but the expected standard.

Could Have

Desirable. Worth doing if time allows after Musts and Shoulds are secure. These are the items that make the product polished, complete, or delightful, but whose absence wouldn't prevent shipping.

Won't Have (this time)

Explicitly excluded from this timebox. The parenthetical is important: Won't Have items are not killed, they are deferred. They go back into the backlog for a future timebox. Making the deferral explicit prevents the constant low-level argument over scope that would otherwise consume team energy.

The Discipline Underneath

MoSCoW works only when the buckets carry real weight. The most common failure is the everything-is-Must problem: stakeholders, asked to prioritize, label every item Must on the grounds that everything is important. That is not prioritization; it is a list with the word "must" written next to each row.

DSDM's guidance is that Musts should represent at most 60% of the planned effort for the timebox, leaving 40% in Shoulds and Coulds to flex against reality. Teams that can't fit their candidate Musts into 60% of capacity don't have a prioritization problem — they have a scope problem, and MoSCoW has just surfaced it.

The deeper test: a Must should be defensible against the cancellation question. "Would we cancel this release if this single feature didn't ship?" Most candidate Musts melt under that question. The ones that survive are the real ones.

How to Run a MoSCoW Session

1. Establish the timebox

MoSCoW is always relative to something — a release, a sprint, a quarter. "Must" without a timebox is meaningless. Confirm the boundary: "We are MoSCoWing what ships in the November release."

2. Confirm capacity

Estimate what fits in the timebox. Velocity, throughput, capacity in days — whatever the team uses for its own forecasting. The 60% Must guideline only works against a real capacity number.

3. Generate the candidate list

Backlog items, stakeholder requests, technical needs, compliance work — everything that might want to be in scope.

4. First-pass bucketing

Each item gets initial assignment to a bucket. Stakeholders, Product Owner, and team go through together. Disagreements are noted, not resolved yet.

5. Pressure-test the Musts

This is the most important step. Walk through each Must and apply the cancellation question. Items that don't pass move to Should. Watch for Must inflation; it is almost always present.

6. Check capacity fit

Sum the effort of the Musts. If they exceed the 60% guideline, the team has too many candidate Musts and the conversation continues. Either some Musts become Shoulds, or the timebox needs to grow.

7. Confirm and publish

The result is published — visible to stakeholders, team, and anyone with skin in the game. The Won't Have list is published too: explicit deferral prevents quiet re-introduction.

Common Pitfalls

• Must inflation: every item is a Must. The 60% guideline is the antidote, but only if leadership backs the team in applying it.
• Vanishing Won'ts: items quietly migrate from Won't Have to Could Have to Must during the timebox. Re-MoSCoWing under pressure is fine; silent reclassification is not.
• Soft Won'ts: items marked "Won't this time, but maybe later" without a real plan to revisit. They linger as scope debt.
• MoSCoW without a timebox: "prioritizing the whole roadmap" with MoSCoW is meaningless. The technique works against a bounded set of work.
• Imposed MoSCoW: stakeholders presented with a buckets list and asked to sign off. The conversation that produced the buckets is where the value is — not the document.
• One-time exercise: MoSCoW done at planning and never revisited. As reality unfolds during the timebox, items often need to move. Re-MoSCoW deliberately.

When MoSCoW Fits

• Fixed time, fixed cost contexts where scope is the only variable.
• Stakeholder conversations where the goal is to surface real priorities versus theater priorities.
• Release planning, sprint planning, project kickoffs.
• Vendor or contract negotiations where scope clarity matters.

When Something Else Fits Better

• Continuous-flow contexts where there is no fixed timebox — WSJF or cost of delay may work better.
• Highly uncertain work where the team's understanding will change weekly. MoSCoW lists go stale quickly under such conditions.
• Long-range portfolio decisions, where the time horizon makes the cancellation test meaningless.

Coaching Tips

Apply the Cancellation Test

For every Must, ask: "Would we cancel the release if just this didn't ship?" Watch how the Must list shrinks.

Hold the 60% Line

When Musts exceed 60% of capacity, the team has too many. Hold the line on the guideline rather than rationalizing it away.

Publish the Won't List

Won't Have items belong on the same visible artifact as the Musts. Hiding the Won't list invites quiet re-inclusion later.

Re-MoSCoW Mid-Timebox

When reality forces changes, redo the buckets deliberately rather than letting items drift. The discipline is the structure, not the original assignment.

Make the Conversation the Product

The bucket assignments matter less than the conversation that produced them. A MoSCoW done in one stakeholder's head and presented to the team is a list, not a prioritization.

Watch for Soft Won'ts

"Won't this time but probably next time" is not deferral, it's debt. If the team isn't ready to actually say no, name that and have the harder conversation.

Summary

MoSCoW's strength is its simplicity. Four buckets, one timebox, one explicit deferral list — almost anyone can apply it after a five-minute briefing. Its weakness is exactly the same: the simplicity makes it easy to use sloppily. The 60% guideline, the cancellation test, and the explicit Won't list are what separate the discipline from the wallpaper.

Teams that use MoSCoW well treat it as a structured conversation, not a document. The point isn't to produce a four-column spreadsheet; it's to force stakeholders to name what they would actually cancel a release over and what they wouldn't. That conversation, done honestly, is where the real prioritization happens.

Back to Prioritization