MoSCoW Method: Prioritize Must, Should, Could, and Won't

The MoSCoW method is a prioritization technique that sorts every requirement into four buckets: Must have, Should have, Could have, and Won't have (this time). Created by software consultant Dai Clegg and now standard in DSDM and Agile, it forces honest trade-offs so you ship what genuinely matters within a fixed deadline.

Quick Answer: MoSCoW splits scope into Must, Should, Could, and Won't-have-this-time. "Must haves" define the minimum viable release and should be capped so they never eat all your effort. "Won't have" means not now, not never.

Most founders don't have a prioritization problem. They have an everything-is-important problem. Every feature feels essential, every stakeholder has a favorite, and the roadmap grows until the deadline arrives and nothing is finished. MoSCoW is a small, teachable ritual that breaks that pattern. Instead of ranking a hundred items on a fuzzy 1-to-10 scale, you drop each one into one of four plainly-named boxes and defend where it lands.

This guide walks through why binary buckets beat a ranked wish list, what each of the four categories actually means, how to run a MoSCoW session without letting "Must" swallow everything, and the mistakes that quietly turn the method back into a wish list. If you're validating a new idea, pair this with a broader look at how to validate a startup idea before you build so you're prioritizing the right problems in the first place.

Why Binary Priorities Beat a Ranked Wish List

MoSCoW works because it replaces a slippery numeric ranking with a small set of named commitments, and each category carries a real consequence. A ranked list lets you pretend everything near the top is equally urgent; four labeled buckets force you to say out loud what you'll drop.

Numeric priority scores fail in a predictable way. When everything can be a "9 out of 10," everything becomes a 9. There's no natural ceiling and no forcing function, so the list inflates. Worse, a rank of "priority 14" tells a developer nothing about whether the release can ship without it.

MoSCoW fixes this by attaching meaning, not just order, to each level:

• Each label is a decision, not a position. "Must have" is a promise the release is worthless without; "Won't have" is an explicit, recorded agreement to defer.
• The categories are legible to everyone. A designer, an investor, and a first engineer all read "Could have" the same way — no decoding a spreadsheet.
• Deferral is built in. The "Won't have" bucket gives ideas somewhere respectable to go, so saying no feels like scheduling rather than rejection.

That last point matters more than it looks. Half of prioritization is emotional — stakeholders resist cutting their idea because "cut" feels permanent. Naming a "Won't have (this time)" bucket reframes the conversation from whose idea dies to what fits this deadline. For a deeper walkthrough of facilitating those trade-offs, see our companion piece on how to prioritize features with the MoSCoW method.

The Four MoSCoW Categories at a Glance

MoSCoW's four categories describe how essential a requirement is to a specific release with a fixed deadline, not its permanent worth. The letters come from the first initial of each category, with the O's added to make the acronym pronounceable.

The table below summarizes what each bucket signals and how it behaves under deadline pressure. Read it as a shared vocabulary before the detailed sections that follow.

The key insight from this table: only the top row is truly rigid. Everything below it is a spectrum of "we'd like to, budget permitting." That flexibility is the point — it's what lets a team hit a hard date while still knowing exactly what got sacrificed and why.

Because these labels are tied to this release, an item can move between categories over time. A "Could have" in your MVP might become a "Must have" in the version you take to enterprise buyers. Now let's define each bucket precisely.

Must Have: The Non-Negotiable Core of This Release

A "Must have" is a requirement without which the release has no value — it's unusable, unsafe, unlawful, or simply pointless to ship. If you can launch and deliver the core promise without an item, it is not a Must have, no matter how loudly someone advocates for it.

A useful test some practitioners use: ask "what happens if this isn't delivered?" If the honest answer is "we cancel the release" or "we ship something illegal or broken," it's a Must. If the answer is "it's ugly but it works" or "there's a manual workaround," it belongs lower down.

Must haves typically fall into a few buckets:

• Core function — the one thing the product exists to do (a checkout that actually charges a card).
• Legal or compliance — requirements you cannot legally launch without.
• Safety and data integrity — anything whose absence risks users or corrupts data.
• Contractual commitments — a feature you've formally promised for this delivery.

The discipline here is subtraction. Founders instinctively load this bucket because every feature feels core when you're close to it. The whole value of MoSCoW evaporates if Must have becomes the default. Which is exactly why the method comes with a cap — covered in the session section below.

Should Have: Important but Survivable Without

A "Should have" is a requirement that is important and will hurt to leave out, but whose absence does not break the release. The product still delivers its core promise; users just feel the gap, or fall back on a workaround.

The line between Must and Should is the sharpest edge in the whole method, and it's where most debate happens. The clarifying question is about pain versus failure: a missing Should have causes pain, inconvenience, or a clunky manual step — but the release still functions and delivers value. A missing Must have causes failure.

Consider a few examples of the distinction:

• Password reset by automated email is often a Should have; support can reset accounts manually for launch week. The login itself is a Must.
• Bulk export might be a Should have if users can export one record at a time in the meantime.
• Detailed analytics dashboards frequently sit here — valuable, but the product works while you build them.

Should haves are your primary flex budget. When a deadline tightens, this is the layer you renegotiate first among the important items, precisely because each one has a survivable workaround. Documenting that workaround next to each Should have makes the eventual cut much easier to accept.

Could Have: Desirable, Low-Cost to Drop

A "Could have" is a genuinely nice addition whose absence causes only minor inconvenience — the classic "nice to have." These are the first things to go when time runs short, and dropping them should barely register with users.

Could haves are the release's shock absorber. Because they're low-impact, they give the team room to protect the deadline: if you fall behind, you quietly drop Could haves before touching anything above them. If you're ahead, they're the reward you deliver "for free."

Typical Could haves include cosmetic polish, minor convenience shortcuts, extra customization options, and small delighters that improve the experience without changing whether the product does its job. The risk with this bucket isn't putting too much in it — it's promising it. Treat every Could have as genuinely optional in your own head, and never let a stakeholder hear "Could have" as "will have." If an item can't survive being dropped without a broken promise, it was never a Could have.

Won't Have (This Time): Deliberately Out of Scope, For Now

A "Won't have (this time)" is a requirement the team has explicitly agreed not to deliver in the current release. The parenthetical is essential: it means not now, not never. These items are consciously parked, not rejected.

This is the most underused and most valuable bucket, and skipping it is a classic mistake. Writing down what you won't build does three things a wish list never does:

• It sets expectations. Stakeholders see their idea acknowledged and scheduled-for-later rather than silently ignored, which defuses the "why wasn't my feature even considered" conflict.
• It protects focus. A recorded "Won't have" is a defense against scope creep mid-sprint — when someone lobbies to add it, you point to the agreement.
• It creates a backlog. Today's "Won't have" list is a ready-made candidate pool for the next release's MoSCoW pass.

The reframing power here is real. "No" ends a conversation and bruises a relationship; "Won't have this time" schedules the conversation for later and keeps everyone aligned. If you're weighing which deferred features would actually move the needle later, a satisfaction-based lens like the Kano model versus MoSCoW comparison helps you tell delighters from basic expectations before you promote anything out of this bucket.

How to Run a MoSCoW Session and Cap the Must-Haves

To run a MoSCoW session, gather the people who own the outcome and the people who build it, list every candidate requirement, then place each into a bucket by consensus — while enforcing a hard cap on Must haves so the "minimum" release stays genuinely minimal.

The single most important rule of facilitation is the cap. Left unchecked, Must have inflates until it's just a relabeled wish list. DSDM practitioners commonly recommend that Must haves make up no more than around 60% of the team's effort for a delivery, leaving meaningful room — often a pool of roughly 20% in Could haves — as contingency. The exact percentages matter less than the principle: if almost everything is a Must, you haven't prioritized, you've procrastinated.

A workable session flow:

1. Set the frame. State the deadline, the budget, and the single goal of this release. Every decision is relative to this frame, not the product's whole future.
2. Brain-dump candidates. List every requirement on cards or a board, no filtering yet.
3. First pass — find the Musts. For each item ask "does the release fail without this?" Be ruthless; default items downward.
4. Check the cap. Total the effort in the Must column. If it consumes most of your capacity, you have no contingency — push the weakest Musts down to Should.
5. Sort the rest. Place remaining items into Should, Could, and Won't-have, capturing the workaround for each Should.
6. Record the Won't-haves explicitly. Write them down as agreed scope decisions, not omissions.
7. Revisit each release. MoSCoW is a repeatable ritual; re-run it as priorities and evidence change.

The cap check in step 4 is what makes the method honest. It converts a vague feeling that "we have too much scope" into a visible, numeric fact everyone in the room can see. Prioritizing against real user evidence rather than opinion is what keeps that conversation grounded — which is where validation work feeds directly into a better MoSCoW session.

Keep the session short and repeatable rather than exhaustive. A tight ninety-minute pass that everyone attends beats a sprawling all-day workshop that no one wants to repeat, and repeatability is the whole point: the value compounds when you re-run the exercise each release with fresh evidence in hand. If a single item triggers a long argument, that argument is itself a signal that you're missing data — park the item as a "Won't have" pending research rather than letting one debate stall the whole board.

Common MoSCoW Method Mistakes to Avoid

The most common MoSCoW failure is treating the labels as fixed opinions rather than deadline-relative decisions, which quietly turns four disciplined buckets back into a ranked wish list. A handful of predictable mistakes account for most of the method's disappointing outcomes.

Watch for these traps:

• Overloading Must have. The cardinal sin. When 80% of items are Musts, the method has done nothing. Enforce the effort cap and default items downward.
• Skipping "Won't have." Leaving it empty forfeits the method's best feature: an explicit, agreed scope boundary that resists creep.
• Prioritizing by opinion, not evidence. Buckets decided by whoever argues loudest reproduce the original politics. Anchor placement to user and market evidence.
• Forgetting the "this time" qualifier. Drop it and "Won't have" reads as permanent rejection, poisoning the very conversation the bucket exists to smooth.
• Never re-running the exercise. A one-time MoSCoW pass ages badly. Re-prioritize each release as you learn.
• Confusing effort with priority. MoSCoW ranks importance to the release, not difficulty. A hard-to-build item can still be a Could have.

The through-line: MoSCoW is a discipline, not a spreadsheet. Its value comes from the honesty of the conversations it forces, and every mistake above is a way of dodging that honesty.

Key Takeaways

• MoSCoW sorts requirements into four named buckets — Must have, Should have, Could have, and Won't have (this time) — so priority becomes a commitment with consequences, not a soft numeric rank.
• It was created by Dai Clegg and is standard in DSDM and Agile, designed specifically for delivering the most valuable scope within a fixed deadline.
• Only "Must have" is truly non-negotiable — the release fails without it; everything below is a spectrum of "budget permitting," giving the team a way to protect a hard date.
• Cap the Must haves so they don't consume all your capacity; a common DSDM guideline holds Musts to roughly 60% of effort, preserving contingency for when estimates slip.
• "Won't have" means not now, not never — recording it explicitly sets expectations, defends against scope creep, and seeds the next release's backlog.
• Prioritize on evidence, not volume — the loudest stakeholder is not a data source; ground bucket placement in what users and the market actually need.
• MoSCoW is a repeatable ritual, not a one-time sort — re-run it each release as priorities, learning, and the market shift.

Frequently Asked Questions

What does MoSCoW stand for?

MoSCoW stands for Must have, Should have, Could have, and Won't have (this time). The capital letters are the meaningful initials; the lowercase O's are added only to make the acronym pronounceable. Each word names a category of how essential a requirement is to a specific release.

Who created the MoSCoW method?

The MoSCoW method was developed by software consultant Dai Clegg while at Oracle in the 1990s. It was later adopted as a core prioritization technique within DSDM (Dynamic Systems Development Method) and is now widely used across Agile and product-management practice for scoping releases against fixed deadlines.

What percentage should be Must-have in MoSCoW?

There's no universal rule, but a common DSDM guideline caps Must haves at around 60% of the team's total effort for a delivery, often reserving roughly 20% as Could-have contingency. The precise number matters less than the principle: if nearly everything is a Must, you haven't prioritized and have no buffer for slippage.

Does "Won't have" mean never?

No. "Won't have" carries the qualifier "this time" — it means the item is deliberately out of scope for the current release, not permanently rejected. It's a parked decision that typically feeds the backlog for a future round of prioritization, which is why keeping the "this time" phrasing is important.

How is MoSCoW different from the Kano model?

MoSCoW sorts requirements by how essential they are to delivering a release on a deadline, producing four scope buckets. The Kano model instead classifies features by their effect on user satisfaction (basic, performance, delighter). They're complementary — see our Kano model versus MoSCoW comparison for when to reach for each.

When should I use the MoSCoW method?

Use MoSCoW whenever you have more candidate requirements than time or budget and a fixed deadline forcing trade-offs — scoping an MVP, planning a release, or defining a sprint. It's most valuable when multiple stakeholders disagree about what's essential, because its named buckets and explicit "Won't have" turn opinion clashes into recorded decisions.