The "Must-Have Discipline" Doesn't Solve Your Power Problem. It Formalizes It.

Twenty items land in the Must-Have bucket. Everyone in the room agreed to strict criteria beforehand. Nobody broke the rules. And you still have twenty things you need to prioritize, which was the job MoSCoW was supposed to do in the first place.

The standard fix is more discipline: clearer criteria, executive sponsorship to hold the line, the courage to say "no" to a stakeholder who wants their feature in the Must-Have column. I've run enough of these sessions to have believed that advice myself, for a while.

It doesn't hold up, and not because teams lack discipline. Most of the teams I've worked with apply the criteria exactly as written. The criteria were never the thing deciding the category. Someone in the room was, and sharper criteria don't remove that person. They give them a more defensible-sounding reason to win.

The Advice That Describes the Problem Instead of Solving It

Search "MoSCoW Must-Have inflation" and you'll find the same diagnosis repeated across a dozen articles: everything becomes a Must-Have because teams aren't strict enough about what qualifies. One practitioner put the failure mode plainly: "20 things that are a Must," and the team still hadn't prioritized anything. The prescribed fix is always some version of the same three moves: define Must-Have more narrowly, get a senior sponsor to enforce the definition, and ask the team to be braver about pushback.

That advice quietly assumes the category itself is a neutral test, and that the only thing standing between a clean result and a bloated one is how rigorously the test gets applied. You'll find the same failure pattern described elsewhere: sandbagging entire feature sets into Must-Have, or seniority overriding the category a feature was supposed to earn. Most writers treat it as a culture problem, something more courage and more sponsorship should fix.

Picture the session: a VP insists a specific onboarding animation is a Must-Have. It doesn't meet the written definition (the product ships and works fine without it), but nobody at the table wants to be the one who says so. The facilitator points at the criteria. The VP points at the launch date and their seniority. The category gets decided in about four seconds, and it isn't the criteria that decided it.

None of that is wrong, exactly. It's incomplete in a specific way. "Executive sponsorship" doesn't create a neutral referee. It installs a more senior decision-maker whose judgment now sits inside the category instead of visibly above it. The category still looks objective on the slide. It absorbed someone's authority instead of displacing it.

What the standard advice promises against what teams applying it report in practice. The category survives; the problem moves inside it.

MoSCoW Was Built for a Deadline, Not for a Power Struggle

This isn't a flaw teams introduced by applying MoSCoW badly. It's baked into what the method was built to do. Dai Clegg developed MoSCoW inside DSDM (Dynamic Systems Development Method), a framework built around fixed, timeboxed delivery. The job of the categories was to protect a deadline: decide what absolutely has to ship by the release date, and cut everything else without renegotiating the date itself.

That's a scope-cutting tool. It answers "what fits in the box," not "who gets to decide what fits in the box." As long as the timebox itself did the disciplining, the method worked as designed. The date wasn't moving, so the categories had to hold.

Most teams today don't use MoSCoW that way. They use it on open backlogs, without a hard release date forcing the cut, in planning sessions where the "box" is negotiable and so, it turns out, is everything else. The categories are still there. The thing that used to force a real decision, an immovable deadline, usually isn't.

The categories survived the move. The mechanism that used to force a decision, the deadline, mostly didn't.

Why Weak Requirements Make the Power Question Worse

There's a second layer to this, and it's the one requirements engineering research actually has data on. When researchers ask practitioners which quality problems show up most often and hurt the most, ambiguity is the single most frequent smell type reported, and ties for the most severe alongside verifiability issues. The NaPiRE consortium's long-running practitioner survey finds the same pattern from a different angle: underspecified requirements are among the most consistently named causes of trouble in real projects, not an edge case.

This matters for MoSCoW specifically. A category decision needs something to measure against. "Is this a Must-Have" is only answerable if "this" is precise enough to have a stable meaning in the room. When the requirement itself is vague (say, "improve the checkout flow" instead of a specific, testable change), there's no content sturdy enough to check anyone's judgment against. The category stops being a measurement and becomes a negotiation. And negotiations, unlike measurements, get won by whoever has the most standing to win them.

Sharpen the requirement, and you at least give the room something to argue about besides each other. Leave it vague, and "mut zur ehrlichen Kategorisierung" (courage to categorize honestly) has nothing to be honest about. It becomes a personality trait you're asking people to have, not a decision they can actually make.

The Question MoSCoW Never Asks

The standard advice never gets here, because it's aimed at the wrong layer. "Are our criteria clear enough" is a question about the method. It assumes the method is what's broken. But MoSCoW was never built to answer "who gets to decide." It was built to answer "what fits before the deadline." It borrows whatever authority is already in the room to do that job when the deadline isn't around to do it instead.

The more useful question isn't about the categories at all: who in this room has the last word today, and does everyone here know that? That's a diagnosis you run before reaching for criteria, sponsorship, or courage, not an accusation. Fixing a category problem with more category rigor is intervention without diagnosis: treating the symptom you can see instead of the structure producing it.

This isn't a one-time facilitation problem, though. It's chronic. If the same person's judgment wins the argument in every MoSCoW session, not because their case is stronger but because nobody in the room outranks them, that's a signal, not bad luck repeating itself.

Every organization has two decision structures running at once. One is formal: an org chart, a title, a "who signs off on this" line in a process doc. The other is informal: who people defer to when the formal line doesn't cover the situation, which in a prioritization session it usually doesn't. Nobody's job title says "resolves Must-Have disputes." So the informal structure fills the gap. Whoever has the most standing in the room (tenure, proximity to leadership, sheer volume) becomes the de facto tiebreaker, session after session.

That gap between the two structures doesn't close because a facilitator asks nicely for more courage. It closes, if it closes at all, when someone looks at the organization itself and asks where that authority should formally sit. That's a different kind of question than anything a MoSCoW template was ever built to answer.

What Changes When You Ask It

Nothing about the MoSCoW template needs to change. Four buckets, plain English, still useful for exactly what it was built for: communicating relative importance quickly, under a real constraint. What changes is what you do before the sorting starts. You name, out loud, whose call this is when the criteria run out, not as a formality but as the one piece of information that was missing every time this session went sideways before.

Twenty Must-Haves was never a categorization failure. It was an authority question, wearing a categorization costume. Ask that question first, and the MoSCoW session stops being the place where it gets fought out in disguise.

This piece stays inside MoSCoW mechanics on purpose. Requirements Engineering for modern Software-Teams goes deeper into writing requirements precise enough to survive a session like this. The organizational half of the question, how to actually diagnose decision authority in a team before trying to change it, is the subject of Speclr's upcoming course on lateral leadership through organizational understanding (Kurs #7), currently in production.

Further Reading

Requirements Engineering for modern Software-Teams

This stays inside MoSCoW mechanics. This course goes deeper into writing requirements precise enough to survive a prioritization session in the first place.

View the course