MoSCoW prioritization: the right way to run it

MoSCoW is a stakeholder alignment tool, not a backlog sorting tool. That distinction is why most teams get it wrong: they treat it as a solo PM exercise, stuff Must Have until it eats 90% of capacity, and then wonder why the sprint still blows past scope. The framework was created by Dai Clegg at Oracle in the 1990s and formalized in DSDM (Dynamic Systems Development Method), specifically to force shared commitment on what a team will and will not ship in a fixed window. Without the fixed window, the four buckets are meaningless.

The four buckets with their qualifying tests

Must Have is the release baseline. The DSDM test: “Would we cancel or not deploy this release if this requirement were missing?” Legal compliance, security gates, and the core workflow a user purchased to get done qualify. A feature requested by a large customer does not automatically qualify. Be strict: if the honest answer is “no, we’d ship anyway and patch it,” it is not a Must.

Should Have is high-value but not delivery-critical. These ship in the same window when capacity allows. If they slip to the next cycle, the release still stands on its own.

Could Have is the deliberate contingency pool. These are not low-priority items; they are the buffer that makes the sprint resilient. When estimates run long, Could Haves slip first. This is by design.

Won’t Have (this time) is an explicit agreement, not a rejection. It means: this release does not include this item, the team acknowledges it, and they will re-evaluate next cycle. Treating Won’t Have as “low-priority backlog” misses the point entirely. The value of Won’t Have is the word “explicit” — stakeholders are on record that the item is out of scope for this window, which kills the scope creep negotiation before it starts.

The DSDM capacity rules that almost no one uses

DSDM sets a firm ceiling: Must Haves should consume no more than 60% of sprint effort. If your Musts exceed that, you have over-classified; stakeholders have not made real tradeoffs yet. The target allocation for Could Haves is roughly 20% of effort, which gives the team a meaningful contingency buffer. Shoulds fill the gap in between.

If you are running a sprint and Musts account for 85% of capacity, you have not applied MoSCoW. You have applied labeling. When interviewers see a candidate describe a backlog where almost everything is a Must, that is the most common failure mode in prioritization answers.

The three-level hierarchy most teams miss

MoSCoW operates at three distinct levels:

Project level: what must be true for the project to succeed at all.
Increment level: what must be true for Phase 1 (or a major release) to be shippable.
Sprint/timebox level: what must be true for this specific two-week delivery.

Most teams only apply MoSCoW at one level and then wonder why the sprint-level Must Have list keeps growing. An item that is a Should at the project level can be a Must at the increment level because the increment’s job is specifically to prove that capability. Getting clear on which level you are scoping prevents category inflation.

A genuinely hard categorization call

You are scoping a B2B analytics tool for a fixed Q3 release. Three candidates are on the table:

Row-level permissions: enterprise clients require this to sign contracts. Without it, legal cannot approve the procurement.
Custom dashboard templates: the sales team says customers keep asking for this. It is not in any contracts yet.
CSV export with formatting options: existing users export weekly; the current plain-text export works but is painful.

Row-level permissions is a Must. Not because it’s complex to build, but because the release has no enterprise buyers without it. Custom dashboard templates is a Should: high customer demand, real value, but existing users will not cancel if it ships in Q4. The categorization argument is over CSV export. Heavy exporters will complain, but they will not churn over one cycle. That makes it a Could, not a Should, which means the team has a real contingency buffer. The hard call is resisting the “large customer asked for it” pressure that turns Coulds into Musts without the DSDM test to back it up.

How to answer the prioritization interview question

strong

"Before I apply MoSCoW, I anchor on the timebox: MoSCoW is meaningless without a fixed delivery window. Then I run a 60-90 minute facilitated stakeholder workshop and apply the DSDM Must test for each candidate: 'Would we cancel this release if this weren't included?' That's the bar. Not 'is it valuable,' not 'did a customer ask for it.' Then I cap Musts at 60% of sprint capacity. If we're above that, stakeholders haven't made real tradeoffs yet and I run the workshop again. Could Haves get roughly 20% of capacity as deliberate contingency — they can slip when estimates run long. Won't Have is not a rejection; it's an explicit agreement that the team re-evaluates next cycle. I'd distinguish this from RICE: I use MoSCoW when stakeholder alignment is the core tension — competing departments, a hard deadline, MVP scoping. I use RICE when the team is already aligned on goals and I'm optimizing ROI across a backlog of candidates."

weak

"M is Must Have, S is Should Have, C is Could Have, W is Won't Have. I'd list all the features and put the most important ones in Must Have." This recites the acronym without applying any qualifying test. The candidate has no capacity rule, no stakeholder alignment step, and treats Won't Have as a low-priority pile rather than an explicit exclusion agreement. Interviewers see this pattern constantly. The deeper failure is treating MoSCoW as a solo task instead of a shared commitment exercise.

When to use MoSCoW vs RICE

The decision rule: use MoSCoW when stakeholder alignment is the bottleneck; use RICE when the team is already aligned on direction and you’re optimizing ROI across candidates.

MoSCoW is right for a fixed launch window with competing stakeholder priorities. RICE is right for a standard quarterly backlog rank where the goal is clear and you need a defensible scoring method. Mixing them up, running RICE when departments are still arguing about what the release is for, produces precise numbers on top of unresolved politics.

The 2026 reframe

In 2026, with AI making almost anything buildable quickly, the Must bucket is no longer primarily a technical-risk filter. It is a viability and lovability gate. The question is no longer “can we ship this in time?” It is: “Is there a real user who would cancel without this? Is the market willing to fund it?”

That reframe changes how you run the workshop. Instead of asking engineers whether something is feasible, you are asking whether there is a paying customer whose problem this directly solves, and whether that customer would find an AI alternative acceptable. Won’t Have is now often the most strategically important bucket: explicitly naming what you will not build is how you avoid shipping something technically impressive but useful to no one. In a world where building is cheap, the hard work is deciding what not to build, and MoSCoW’s Won’t Have bucket is the only standard framework element designed specifically for that.