MoSCoW Prioritization: Must, Should, Could, Won't

MoSCoW sorts requirements into Must, Should, Could, and Won’t have, giving stakeholders a shared vocabulary for the hardest conversation in delivery: what is truly essential versus merely wanted. Its value depends entirely on defining Must strictly enough that the word still means something.

MoSCoW is a prioritization technique that sorts requirements into four categories: Must have (essential, the delivery fails without it), Should have (important but with a workaround), Could have (desirable, included only if time allows), and Won’t have this time (deliberately out of scope). The capital letters spell MoSCoW, and the method gives stakeholders a simple, shared way to agree what is essential versus optional, which is the foundation of every scope decision. Its power is also its weakness: it only works if Must is defined strictly, because the universal failure mode is that everything becomes a Must have, at which point the prioritization has told you nothing. Applying it well is a core business analyst and functional analyst skill, and the templates for prioritization and the rest of an analyst’s deliverables are in Real-World BA Deliverables.

I have facilitated many MoSCoW sessions, and the entire skill is in holding the line on what Must actually means. Done with discipline, MoSCoW turns a contentious scope debate into a structured, honest conversation; done loosely, it becomes a list where every item is critical and nothing can be cut.

What do the four categories actually mean?

The four categories form a clear hierarchy of necessity, and the precision of each definition is what makes the method work. Must is non-negotiable, Should is important-with-a-workaround, Could is nice-to-have, and Won’t is deliberately deferred.

Must have means the requirement is essential: without it, the delivery has no value or simply fails. This includes legal and regulatory requirements, which are non-negotiable by definition. The test for a Must is severe, the delivery is pointless or broken without it. Should have means important and painful to omit, but with an acceptable workaround, so it can be deferred under pressure without sinking the delivery. A Should is something you really want but could live without for a release if you had to. Could have means desirable, nice to have, included only if time and resources permit, and the first thing to drop when the schedule tightens. Won’t have this time means explicitly agreed to be out of scope for this delivery, recorded as a deliberate decision rather than an oversight.

The gradient from Must to Won’t is a gradient of consequence: what actually happens if this is not delivered. A Must failing breaks the delivery; a Should failing hurts but is survivable; a Could failing is barely noticed; a Won’t was never in. Keeping these distinctions sharp is the whole game, because the moment Should items drift into Must, the categories collapse and the prioritization is lost. This is the same precision discipline that runs through good requirements work: say exactly what you mean, including exactly how essential each thing is.

How do you stop everything becoming a Must have?

You stop Must-have inflation by defining Must strictly and challenging every proposed Must against that definition, because the natural tendency of every stakeholder is to call their requirement essential. Without active discipline, the Must list swells until it is the whole backlog and the method is useless.

The core technique is the challenge question: for each proposed Must, ask “what happens if we do not deliver this?” If the honest answer reveals any acceptable workaround, or that the delivery still has value without it, then it is not a Must, it is a Should at most. This question cuts through the instinct to label everything critical, because it forces the stakeholder to articulate the actual consequence rather than the felt importance. A surprising number of “must haves” turn out to have a workaround once someone asks directly, which demotes them and frees the prioritization to mean something. Regulatory and legal requirements pass this test genuinely, the delivery cannot ship without them, so they remain Musts, which is exactly why the strict definition still lets the real essentials through.

Some teams add a structural guardrail: capping the proportion of effort allowed for Must-haves, for example requiring that Musts be no more than around 60 percent of the planned effort, leaving room for Shoulds and Coulds and a buffer for the inevitable surprises. This forces honest prioritization by making it impossible to call everything a Must, there is simply not enough Must budget. Whether you use a formal cap or just rigorous challenging, the principle is the same: Must must be scarce to be meaningful. Holding that line is the business analyst’s job, and it is often uncomfortable, because it means telling stakeholders their favorite requirement is not actually essential, which is precisely the value the role adds.

Why is the Won’t have category so valuable?

The Won’t have category is valuable because explicitly naming what is out of scope manages expectations and prevents scope creep, recording that a requirement was considered and deliberately deferred rather than forgotten. Stating what you will not do is as important as stating what you will.

The common mistake is to prioritize only the things you are doing, Must, Should, Could, and leave everything else in an undefined limbo. That limbo is where scope creep breeds, because a stakeholder assumes their unmentioned requirement is still coming, and the disagreement only surfaces later, painfully. The Won’t have category fixes this by making the exclusion explicit and agreed: this requirement was on the table, we discussed it, and we decided it is not in this delivery. That record prevents the “I thought we were doing that” dispute, because the decision is documented and was made with the stakeholder in the room.

Won’t have also keeps the door open without keeping the scope open. “This time” is the operative phrase: a Won’t have is not rejected forever, it is deferred from this delivery, which is easier for stakeholders to accept than a flat no and more honest than a vague maybe. This connects directly to the scope discipline of the BRD and the fit-gap analysis, where being explicit about what is in and out is half the value of the exercise. Naming the boundary, on both sides, is what turns prioritization from a wish list into an agreed scope, and it is one of the most underused tools for keeping a delivery on track.

How does MoSCoW drive real scope decisions?

MoSCoW drives scope decisions by giving an agreed order in which to cut when time or resources run short, which they always do. When the deadline tightens, you drop Coulds first, then Shoulds if necessary, while protecting the Musts, and because the categories were agreed up front, the cut is a planned move rather than a panicked argument.

This is the payoff that makes the prioritization worth the effort. Every real delivery eventually faces the moment where not everything will fit, and without prior prioritization that moment is a chaotic, contentious scramble where the loudest stakeholder wins. With MoSCoW agreed in advance, the response is structured: the Coulds were always the first to go, so they go; if more must be cut, the Shoulds are next, by definition survivable with a workaround; the Musts are protected because the delivery fails without them. The hard conversation about what is essential happened earlier, calmly, rather than in the crisis, which is exactly when you do not want to be having it.

This makes MoSCoW especially powerful in time-boxed and agile delivery, where fitting scope to a fixed schedule is the constant reality, and in release planning, where you decide what makes this release versus a later one. It gives the team and stakeholders a shared vocabulary for the trade-off, so “we’ll cut the Coulds” is immediately understood and accepted, having been agreed. The technique does not make the trade-offs go away, nothing does, but it makes them explicit, ordered, and agreed in advance, which is the most a prioritization method can do and exactly what a delivery needs. Facilitating this well, getting honest priorities before the crisis, is a high-value analyst contribution, and the skills around it are part of The Technical Skills Guide for BAs.

The takeaway

MoSCoW sorts requirements into Must (essential), Should (important, with a workaround), Could (nice to have), and Won’t have this time (deliberately out of scope), giving stakeholders a shared vocabulary for prioritization. Its value depends entirely on defining Must strictly, challenge every Must with “what happens if we don’t deliver this,” and demote anything with a workaround. Use Won’t have to make the scope boundary explicit and prevent creep, and let the agreed categories drive calm, ordered scope cuts when the deadline tightens.

Apply it with discipline and the hard scope conversation happens once, up front, instead of repeatedly in crisis. Start with Real-World BA Deliverables for the templates and The Technical Skills Guide for BAs for the broader toolkit, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Requirements, Prioritization, Agile, Project Management