The MoSCoW Method: Sort Must-Haves from Nice-to-Haves

The MoSCoW method sorts work into four buckets: Must have, Should have, Could have, and Won't have this time. A Must have is essential and the plan fails without it; a Should have is important but not vital; a Could have is desirable if time allows; and a Won't have is a deliberate decision to leave something out this round. The method is most useful when you have a fixed deadline and have to decide what actually fits inside it.

Where MoSCoW comes from

MoSCoW was developed in the 1990s by software consultant Dai Clegg and became a staple of agile and DSDM project delivery. The capital letters stand for the four categories; the lowercase o's just make the acronym pronounceable. It spread because it solves a problem every team faces: a long list of desirable things and not enough time to do them all. Instead of pretending everything is top priority, MoSCoW forces an explicit, shared decision about what is truly essential.

Although it was born in software, the method works for anything with a deadline and a scope: planning an event, launching a product, or even organising a house move. Wherever time is fixed and wants exceed capacity, MoSCoW helps.

What distinguishes MoSCoW from a plain priority list is the word "timebox." The categories are not permanent rankings of importance; they describe what fits inside one particular cycle. A feature can be a Won't-have this quarter and a Must-have next quarter without any contradiction, because the question is always "what belongs in this release, given the time we actually have?" That framing keeps arguments grounded in reality rather than in abstract debates about which idea is objectively best.

The four categories

• Must have. Non-negotiable. Without it the deliverable does not work, the deadline is missed, or a legal or safety rule is broken.
• Should have. Important and painful to leave out, but there is a workaround. It can slip without breaking the plan.
• Could have. Desirable and low-cost to include, the first thing dropped when time runs short.
• Won't have (this time). Explicitly out of scope for this cycle. Parked openly so nobody assumes it is still coming.

The sharpest test is for the Must category. Ask: "What happens if this is left out?" If the honest answer is a workaround or a minor annoyance, it is a Should, not a Must. Most teams discover that far fewer things are genuinely essential than they first believed.

The 60% rule

The most common MoSCoW mistake is labelling everything a Must have. That defeats the purpose: if everything is essential, you are back to a flat list with no priorities. A widely used guideline is to keep Must-haves to roughly 60% of your available effort, with Should-haves and Could-haves making up the rest. That remaining 40% is not padding; it is the buffer that absorbs the bugs, sick days and surprises every real project runs into. When something goes wrong, you drop a Could have, not a Must have, and the core still ships on time.

A worked example

Imagine you are launching a simple booking website with a hard deadline. Here is how the feature list might sort.

The decision is now unambiguous. If time gets tight, dark mode goes first and discount codes second, while booking and confirmation emails are protected. Just as important, everyone agreed the loyalty system is out, so nobody is surprised when it is missing at launch.

How MoSCoW compares to other methods

MoSCoW answers "what fits in this fixed timebox?" rather than "which single task is next?" For a personal daily list, the lighter ABCDE method is quicker, since it ranks individual tasks by consequence. When you need to compare whole projects by their expected value and effort rather than sort within one deadline, RICE scoring gives you a number to rank by. And if your real struggle is that genuinely important and urgent work keep colliding, the Eisenhower Matrix exposes that tension directly.

Making it work in practice

MoSCoW is a conversation tool as much as a sorting tool. Its real power appears when a team or stakeholders agree on the categories together, because the labels record a shared decision rather than one person's opinion. When a client later asks why their favourite feature was dropped, you can point to a jointly agreed label instead of relitigating the whole plan. Revisit the list at the start of each cycle, and be willing to promote a Should to a Must only when you also demote something to keep the 60% balance. Priorities are a fixed budget: you cannot add to one bucket without taking from another.

One last habit makes MoSCoW durable: write a one-line reason beside each label, as in the example above. The reasons are what let you defend the plan weeks later and what let you re-sort quickly when circumstances change. A label without a reason is just an opinion; a label with a reason is a decision you can stand behind.

Everything cannot be a priority. The moment you admit that, and name what you will not do this time, the work that matters finally has room to get done.