MoSCoW Prioritization That Doesn't Collapse

MoSCoW doesn't fail because the framework is weak. It fails because nothing in it stops a stakeholder from calling their item a Must, and once three or four people do that, the other three categories stop meaning anything.

The direct answer: MoSCoW prioritization sorts requirements into Must, Should, Could, and Won't have, and it collapses when Must absorbs everything because the method has no built-in enforcement. The fix isn't a better definition of "Must." It's a hard cap on how much delivery effort Must have is allowed to consume, a single named person who resolves disputes, and a re-run of the whole exercise at every stage boundary rather than once at kickoff.

What MoSCoW Prioritization Actually Sorts

Category	What it means	Typical failure mode
Must have	Ships, or the release doesn't happen	Absorbs everything once enforcement is missing
Should have	Important and painful to cut, but survivable	Gets relabeled Must under stakeholder pressure
Could have	Genuinely optional, the deliberate slack	Cut first when Must overflows, leaving no contingency
Won't have (this time)	Explicitly out of scope for this round	Reappears mid-project as a "quick add" nobody logged

Everything past this four-way split is commentary. The method itself is simple enough to explain in a meeting; keeping it honest for the length of a project is the actual job.

Why "Must" Eats the Other Three

MoSCoW has no gatekeeping built into it. Every stakeholder has an incentive to protect their own item, and calling it a Must is the cheapest way to protect it, so without a rule that pushes back, a PM facing that pressure one item at a time usually accepts the label rather than start an argument. Multiply that across a backlog of forty items and the split that started as a genuine 60/20/20 negotiation drifts, item by reasonable-sounding item, toward 90% Must have and a Could have column that exists in name only.

The chart above is the same forty items either way. The left split happened by default, one accepted argument at a time. The right split happened because someone enforced a number.

The Fix: Cap Must Have at 60% of Effort

DSDM, the methodology MoSCoW originated in, states the guidance in effort terms, not item counts: getting Must have effort to a level "where the team's confidence to deliver them is high, typically no more than 60% Must have effort," with a further roughly 20% held as Could have contingency. DSDM is explicit that going above that 60% line raises real delivery risk unless the estimates, the approach, and the team are all unusually well understood. The percentage applies to estimated effort to deliver, not the raw count of requirements. Ten small Must haves and two large ones can both describe a legitimate 60%, or a wildly illegitimate one, depending on the estimate behind each line.

Who Breaks the Tie: Name an Arbiter Before You Need One

Decide who resolves a Must have dispute before the first dispute happens, not during it. Product owner, sponsor, or PMO lead all work as the arbiter; what matters is that it's one person, named in advance, and that everyone in the room already agreed to accept that person's call. Litigating who gets to decide in the middle of a heated prioritization session is how a 45-minute meeting becomes a 3-hour one, and it's usually the loudest stakeholder, not the most informed one, who wins an undecided fight.

What to Do When a Stakeholder Won't Move Their Item

Ask what specifically breaks if the item ships as Should have instead of Must have. Not rhetorically, specifically: which downstream task fails, which contract clause is violated, which regulatory deadline is missed. Most of the time nothing concrete breaks, the stakeholder just doesn't want to risk the item getting cut, and naming the actual consequence, or the absence of one, resolves the argument faster than restating "everything feels important" back and forth. When something genuinely does break, the item earns its Must have status, and the cap forces the harder, more useful question: what else moves to keep the total under 60%.

Re-run It at Every Stage Boundary

A Must have list agreed at kickoff describes what the team understood at kickoff. Portfolio and priority fights rarely happen because the original prioritization was wrong; they happen because nobody re-ran it after the project's understanding changed. Treat each stage or phase boundary as a mandatory re-prioritization checkpoint, not an optional one, and revisit the 60% cap against whatever's actually been learned since the last checkpoint. If your backlog grooming already has a regular cadence, fold MoSCoW re-runs into it rather than scheduling a second recurring meeting nobody attends.

The cap and the arbiter solve the mechanics. The harder part is usually a scope conversation dressed up as a prioritization one, and the scope-creep conversation is worth reading alongside this if the same three items keep getting re-argued every sprint. MoSCoW works when the four buckets stay honest; the discipline that keeps them honest is the actual deliverable, not the four letters.