MoSCoW Method

What is MoSCoW Method?

The MoSCoW Method is a prioritization framework that sorts requirements or features into four buckets: Must have, Should have, Could have, and Won't have (this time).

The technique is commonly attributed to Dai Clegg, who developed it in 1994 for rapid application development and published it in "Case Method Fast-Track: A RAD Approach" (Wikipedia). It found its widest use from 2002 onward inside the Dynamic Systems Development Method (DSDM), and the Agile Business Consortium now maintains the canonical definitions as part of the DSDM framework.

Each bucket answers a different question. A Must have is something you'd cancel the project over if it didn't ship. A Should have is important but the project stays viable without it, sometimes with a workaround. A Could have is wanted but has less impact if left out. A Won't have is something the team has explicitly agreed not to build this time, which is what makes MoSCoW different from a simple wishlist: it forces a stated no. The Agile Business Consortium also recommends a budget for the split, typically no more than 60 percent of effort going to Must haves and around 20 percent to Could haves, so that Should and Won't stay honest categories rather than dumping grounds (Agile Business Consortium).

Why it matters for product-market fit

MoSCoW earns its place in the Decide stage of Produck's Listen, Diagnose, Decide, Ship loop. By the time you're sorting a backlog into Must, Should, Could, and Won't, you should already have Listened to real user feedback and Diagnosed which problems actually recur. MoSCoW is where that diagnosis turns into a shipping commitment.

Where MoSCoW helps most is forcing the Won't have conversation. Most roadmap arguments aren't about what to build first, they're about what nobody wants to say no to. A four-bucket sort with a real Won't have column makes that refusal visible and dated, instead of leaving every unshipped idea in permanent limbo. That matters for product-market fit specifically, because teams chasing PMF tend to drown in feature requests that all sound urgent. MoSCoW doesn't rank them against each other the way RICE Scoring does with a formula, it sorts them against a fixed bar: would we cancel without this.

That's also its limit. MoSCoW tells you what's non-negotiable, not what will most move the needle for users who haven't asked for anything yet. Pairing it with something like the Kano Model, which separates basic expectations from delighters, covers the gap: MoSCoW protects scope, Kano protects surprise.

When it works, and when it doesn't

It works when

• You have a hard deadline or fixed budget and need an honest cut line, not a ranked list.
• Stakeholders keep treating every request as equally urgent and you need a forcing function to get an explicit Won't have.

It falls short when

• Your inputs are guesses rather than real user feedback, so "Must have" ends up meaning "loudest person in the room."
• You need to compare many similar-sized features against each other with real numbers. A coarse four-bucket sort can't do that; a scoring model can.
• The team never revisits Won't have items, so they quietly become permanent no's instead of deferred yes's.
• Everything gets marked Must have because no one wants to own the tradeoff. That's not a MoSCoW failure, it's a sign the exercise was skipped rather than done.

How to apply it

1. Pull the current backlog straight from what you've Listened to and Diagnosed, not from a brainstorm. Every item should trace back to a real user or a real pattern in feedback.
2. For each item, ask the cancel-the-project test: if this doesn't ship, does the release still make sense? If yes, it's not a Must have.
3. Sort the rest into Should have and Could have based on impact if it slips, not on who's asking loudest.
4. Write down your Won't have list explicitly and put a date on it. This is the step teams skip, and it's the one that makes MoSCoW worth doing.
5. Check your Must have total against a rough effort budget. If Must have is eating most of the timebox, something else needs to move down or out.
6. Ship the Musts, note the Shoulds and Coulds for the next cycle, and feed what you learn back into Listen before you run the sort again.