The MoSCoW Method: How to Prioritize What Actually Matters

Most software projects don’t fail because the team can’t write code.

They fail because everything is treated as important.

A backlog with 80 items, all marked “high priority,” is not a plan. It is a way of postponing a decision. Someone still has to choose what gets built this week, what waits, and what never happens. If you don’t make that choice on purpose, the choice gets made by whoever shouts loudest, whichever ticket is newest, or whichever fire is currently burning.

The MoSCoW method is one of the simplest tools I know for making that choice explicit.

It forces a team to sort work into four buckets:

• Must have
• Should have
• Could have
• Won’t have (this time)

The vowels are only there so the name is pronounceable. The method itself is not complicated. The value is in the conversation it creates: what is truly required for this release, and what are we willing to drop if time, budget, or attention runs out?

What is MoSCoW?

MoSCoW is a prioritization technique that came out of the Dynamic Systems Development Method (DSDM) in the 1990s. Dai Clegg is usually credited with introducing it as a way to negotiate scope against a fixed deadline.

That origin still matters. MoSCoW was designed for situations where time is more fixed than scope. You have a date, a sprint, a launch window, or a budget. You do not have infinite capacity. Something has to give.

A useful way to picture it:

All the work people want
            │
            ▼
     ┌──────────────┐
     │   MoSCoW     │
     └──────┬───────┘
            │
   ┌────────┼────────┬────────────┐
   ▼        ▼        ▼            ▼
 Must     Should   Could        Won't
 have      have     have         have
   │        │        │            │
   ▼        ▼        ▼            ▼
 Ship it  Ship if  Ship if     Not this
 or fail  we can   there's     release
          time     leftover
                   time

The method does not estimate effort. It does not score business value. It does not replace product sense. It answers a narrower, more useful question:

If we run out of time, what is still allowed to be missing?

That question is uncomfortable. It is also the one most teams avoid.

The four categories

The labels look obvious. They are not, until you define them tightly enough that two people would put the same item in the same bucket.

Must have

A Must is not “we really want this.”

A Must is something without which the release is a failure. If this item is missing, the product does not work, the user cannot complete the core job, or you cannot legally or safely ship.

Good tests for a Must:

• If we cut this, is the product unusable?
• If we cut this, do we fail a hard constraint (security, compliance, a contract, a platform rule)?
• Would we delay the release rather than ship without it?

If the honest answer to those is “no,” it is not a Must.

Examples in software:

• Users can sign in and reach their own data.
• Payments can be charged and receipts recorded.
• The app does not store secrets in plaintext.
• The core workflow the product is named after actually works.

Musts should be rare. If half the backlog is Must, you have not prioritized. You have relabeled ambition as necessity.

Should have

A Should is important. You expect to ship it. The product is noticeably worse without it. But the release can still go out if it slips.

Shoulds are the work that makes the product good rather than merely viable.

Examples:

• Password reset.
• A sensible empty state instead of a blank screen.
• Export, because power users asked for it.
• Keyboard shortcuts in a tool people use all day.
• A performance improvement that users will feel, but that does not make the product unusable today.

The distinction from Must is this: you would be disappointed to miss a Should. You would not cancel the launch.

Could have

A Could is desirable if time is left. It is not load-bearing. Cutting it should not require a new plan.

Coulds are often the items that sneak into a sprint because they are small, interesting, or politically easy. MoSCoW’s job is to keep them visible as optional.

Examples:

• A nicer animation.
• An extra filter on a list that already has search.
• Dark mode, if the product is still missing the main workflow.
• A second integration when the first one already covers the launch audience.

Coulds are not worthless. They are the first things you drop when a Must or Should starts slipping. That is their purpose.

Won’t have (this time)

This is the most useful category, and the one teams skip.

A Won’t is not “never.” It is “not in this timebox.” Writing it down does two things:

1. It stops the item from being silently re-litigated every week.
2. It tells stakeholders the idea was heard, not ignored.

Examples:

• A native Android app while you are still proving the iOS workflow.
• Multi-workspace accounts before single-user accounts are solid.
• An admin analytics suite before anyone is using the product enough to generate data.

“Won’t have this time” is a release decision, not a value judgment. The item can come back next cycle. Until then, it is out of scope on purpose.

Why the method works

Prioritization frameworks often try to produce a ranked list from 1 to n. That feels precise. It is also usually fake precision. Two features are rarely comparable on a single number, and the ranking still collapses the moment someone asks, “What if we only have two weeks?”

MoSCoW works because it is categorical, not numerical.

It creates a shared language:

"Is this a Must for October, or a Should?"

That sentence is more useful than:

"This is a P1."

P1, P2, and P3 tend to inflate. Everything becomes P1. MoSCoW inflates too if you are sloppy, but the definitions fight back. “Would we delay the release?” is harder to game than “is this important?”

It also makes trade-offs visible. If a new request arrives mid-sprint, you do not ask “can we also do this?” You ask:

Which existing Must, Should, or Could does this replace?

If it replaces nothing, it is a Won’t for this round.

The 60 / 20 / 20 capacity rule

DSDM’s practical advice is to avoid filling the timebox with Musts.

A common split of estimated effort looks like this:

Must have     ████████████░░░░░░░░  up to ~60%
Should have   ████░░░░░░░░░░░░░░░░  ~20%
Could have    ████░░░░░░░░░░░░░░░░  ~20%
Won't have    (explicitly excluded)

The numbers are a guideline, not a law. The point is the buffer.

If 100% of the plan is Must, any surprise — a bug, a dependency, a wrong estimate — turns into a missed deadline or a silent quality cut. Shoulds and Coulds are the slack that lets Musts still ship when reality shows up.

I treat it as a health check:

• Too many Musts: you are not prioritizing; you are hoping.
• No Coulds: you have no release valves.
• No Won’ts: you have not actually said no.

How I use it in software work

I don’t run a formal MoSCoW workshop for every small change. I do use the same four questions whenever a list of work is competing for the same deadline.

1. Name the timebox first

MoSCoW without a timebox is just a wishlist with nicer labels.

Decide what “this time” means before you sort anything:

• this sprint
• this App Store release
• this month
• the MVP
• the next client demo

The same feature can be a Must for a demo and a Could for a public launch. The category is relative to the deadline, not an eternal property of the idea.

2. Write the outcome, not the feature list

Start with what has to be true at the end of the timebox.

For an indie app release, that might be:

A new user can download the app, complete the main task, and understand whether they want to keep using it.

Then sort work against that outcome. Features that do not serve it have a hard time remaining Musts.

3. Sort with someone who will say no

Doing MoSCoW alone is easy and slightly pointless. You already know what you like.

The useful version is a short conversation with whoever owns the date: you, a teammate, a client, a designer. Read each item out loud and put it in a bucket. When people disagree, that is the work. The method is a prompt for disagreement, not a substitute for it.

A disagreement I trust:

“I think onboarding tooltips are a Must.”

“Would we delay the release if they weren’t done?”

“No.”

“Then they’re a Should or a Could.”

4. Keep Musts small and testable

A Must like “the app should feel polished” cannot be finished, so it cannot be prioritized.

Rewrite until you can tell, on the last day, whether it shipped:

Vague Must	Usable Must
Make onboarding good	First-run flow gets a user to the main screen
Handle payments	A user can subscribe and cancel in-app
Improve performance	Cold start under 2 seconds on a 3-year-old phone
Support teams	Two users can share one workspace

If you cannot write an acceptance check, it is not ready to be a Must.

5. Re-sort when the facts change

MoSCoW is not a one-time ceremony. Midway through a timebox, a Should can become a Could because a Must grew. A Won’t can become a Must because a store review or a legal constraint appeared.

Update the labels in public. A stale MoSCoW list is just another backlog.

A concrete example: shipping a small app

Suppose you are building a simple iPhone app: capture a thought, tag it, find it later. The timebox is a first public release in six weeks.

Must have

• Create, edit, and delete a note
• Search notes
• Data persisted on device
• Privacy policy and basic App Store requirements
• No crash on the main paths

Should have

• iCloud sync
• Tags
• Home Screen widget
• Share extension (“save this from Safari”)

Could have

• Custom fonts
• Home Screen quick actions
• Markdown preview
• Export to Markdown files

Won’t have (this time)

• Collaboration
• Web app
• AI summarization
• Apple Watch app
• Folders inside folders

This list is not a roadmap for the product’s life. It is a decision about this release.

If iCloud sync slips in week five, the app can still ship. If create-and-search slips, you wait. That is the whole method, applied.

The Won’t list is doing real work here. Collaboration and AI are interesting. They are also a different product. Writing them down as Won’ts keeps the next six weeks honest.

Where it fits with other methods

MoSCoW does not replace everything else.

Method	What it is good at	What it does not do
MoSCoW	Scope vs a deadline	Scoring value or effort
RICE / ICE	Comparing many ideas by a formula	Saying what can slip
Eisenhower matrix	Urgent vs important for personal time	Release scope
Story points / estimates	How big something is	Whether it belongs in this release
OKRs	Whether the work serves a goal	Sequencing inside a sprint
User story mapping	Walking a user’s journey	Cutting against a date

A healthy sequence, when you need one:

Goal (what success is)
  → Journey / story map (what the user does)
  → MoSCoW (what this timebox includes)
  → Estimates (whether the Musts fit)
  → Build

If estimates say the Musts do not fit, you do not quietly turn Shoulds into Musts. You cut Musts until they fit, or you move the date. Pretending otherwise is how “MVP” becomes “everything we thought of in the first meeting.”

Common failure modes

I have seen MoSCoW become useless in a few predictable ways.

Everything is a Must

This is the default failure. Stakeholders learn that Must means “we will definitely do it,” so every item is promoted.

Fix: apply the delay test. If you would still ship without it, it is not a Must. Cap Musts by capacity, not by desire.

Won’t is treated as never

People then refuse to put anything in Won’t, because they do not want the idea killed.

Fix: always say “Won’t have this time.” Keep a parking lot. Review it at the start of the next timebox. Trust in the method depends on Won’ts being allowed to come back.

Categories are assigned by whoever wrote the ticket

Authors over-rank their own work.

Fix: sort in a room (or a call) with a shared list. The person who wants the feature argues for the category. The person who owns the date can veto a Must.

MoSCoW is applied to tasks instead of outcomes

“Write the migration,” “design the icon,” and “set up CI” are not Must/Should/Could items on their own. They are work required to deliver an outcome that is a Must.

Fix: prioritize user-facing or product outcomes first. Sequence engineering tasks underneath. CI might be a Must for shipping, even if users never see it. Call that out honestly: “We cannot release without this,” not “this ticket is important to me.”

The list is made once and laminated

A MoSCoW board from kickoff, never touched, will be wrong by week three.

Fix: spend ten minutes at the start of each week asking: did any Must become a Should? Did any Could get promoted for a real reason? Did a new Won’t appear?

“Won’t” is used to avoid a hard no

Sometimes the honest answer is “we are not going to build this.” Using Won’t as a polite stall creates a zombie backlog.

Fix: if an item has been a Won’t for three cycles and nobody can describe when it would become a Should, archive it. Prioritization includes forgetting.

Using MoSCoW on personal work

The same four buckets work when the “stakeholder” is you.

A week of side-project time is a timebox. Inbox, ideas, and guilt will all claim to be Musts. They are not.

Example for a weekend:

Must: fix the crash that blocks the main screen. Should: write the release notes. Could: tweak the icon. Won’t (this weekend): rewrite the networking layer.

Personal MoSCoW is mostly a defense against optional work that feels productive. Coulds are often the fun parts. That is fine — after the Must is done.

A lightweight template

When I actually write this down, it is rarely a fancy board. A note is enough:

Timebox: [date or release]
Outcome: [one sentence]

Must have
- [ ] ...
- [ ] ...

Should have
- [ ] ...

Could have
- [ ] ...

Won't have this time
- ...
- ...

Capacity check
- Musts fit in ~60% of the time?  yes / no
- What we will cut first: [top Could, then Should]

If the Musts do not fit, the template has already done its job. The remaining work is cutting, not coloring in more labels.

What MoSCoW is not

It is not a way to make a bad product strategy look rigorous.

It will not tell you what to build. It will not tell you whether the product should exist. It will not resolve a fight about vision. If the team does not agree on the outcome of the timebox, sorting features is theater.

It is also not a substitute for talking to users. A Must that nobody needs is still a Must only in the sense that you decided to waste the release on it.

Use it for what it is good at: negotiating scope against a constraint, in language everyone can reuse.

Final thoughts

The MoSCoW method looks almost too simple to be worth a name. Four labels. A deadline. A conversation about what happens if you run out of time.

That simplicity is the point.

Software work generates more ideas than any calendar can absorb. The failure mode is not a lack of ideas. It is a refusal to rank them in a way that survives contact with a date.

Must means we delay if it is missing.

Should means we are unhappy if it is missing, and we still ship.

Could means we will take it if the Musts and Shoulds leave room.

Won’t means we are not doing it this time, and we are not going to pretend otherwise.

If you only remember one test, remember this one:

Would we delay the release rather than ship without it?

Everything that fails that test can compete for the remaining time. Everything that passes it has to fit. If it does not fit, you do not have a prioritization problem. You have a scope problem, and MoSCoW just made it visible — which is the most useful thing a priority method can do.