What Is the MoSCoW Method? A Simple Way to Prioritize Features

Author: Inputly

What is the MoSCoW method?

The MoSCoW method is a prioritization technique that sorts a list of work into four buckets: Must have, Should have, Could have and Won't have. A Must is something the release cannot ship without, a Should is important but has a workaround, a Could is a nice extra if time allows, and a Won't is agreed out of scope for this round. Dai Clegg created it at Oracle in 1994, and agile and DSDM teams adopted it because it takes minutes and produces a decision instead of a debate. The labels matter less than the argument: asking someone to explain why a feature is a Must is where the method earns its keep. MoSCoW is a scope tool, not a listening tool, so feed it from real user input such as the feedback you collect in the product rather than from opinion.

TL;DR: Sort the backlog into Must, Should, Could and Won't, keep Must at roughly 60 percent of your effort, and record why each Won't item is parked. MoSCoW is fast and needs no scoring maths. Reach for RICE or Kano when you need numbers behind the ranking.

What do the four MoSCoW categories mean?

| Category | Plain meaning | Test to apply | Healthy share of effort | | --- | --- | --- | --- | | Must have | The release cannot ship without it | Remove it and the release is unusable, illegal or unsafe | Around 60 percent | | Should have | Important, but a workaround exists | Painful to leave out, yet there is a manual or temporary path | Around 20 percent | | Could have | Nice if time allows | Small delight, first thing dropped with no damage to the outcome | Around 20 percent | | Won't have | Parked with a written reason | Agreed out of scope for this cycle, revisit on a named date | Zero this cycle |

Two rules keep that table honest. First, a Must is a definition, not a feeling: if deleting the item does not break the release, it is a Should. Second, Won't have is a decision, not a bin. Write the reason and the review date, otherwise the same argument returns next month with a new sponsor.

How do you run a MoSCoW session?

1. Start from a real list. Pull candidates from your public roadmap and the requests users actually voted for, not from the loudest person in the room.
2. Write one line per item: who it is for and what outcome it creates. Items with no user and no outcome get parked before the sorting starts.
3. Sort in silence first. Everyone tags every item alone, then you compare the tags. The disagreements are the useful output.
4. Argue only the Must column. If more than 60 percent of your effort lands there, you have a wish list rather than a plan.
5. Set a cap per bucket before you begin. With a fixed release date, capacity decides what fits, not enthusiasm.
6. Publish the result, including the Won't list, so people see the decision instead of guessing from silence.

A session that ends with a clean Must column and an empty Won't column did not finish. The cuts are the deliverable.

What are the most common mistakes?

• Everything is a Must. When three quarters of the list is critical, nothing is, and the label stops carrying information.
• Must as a vote. The method assumes the definition decides, not the seniority of whoever asked. Otherwise it is just politics with four headings.
• Nothing is actually cut. Won't items quietly return a week later because nobody wrote down the reason they left.
• No effort cap. Without a number for capacity, each bucket grows until the plan is fiction.
• Run once and filed away. MoSCoW is per cycle. A Could this quarter can be a Must the next, and a Should often dies quietly.
• Used as your only input. MoSCoW tells you what to agree on, not what customers want. It needs evidence underneath it, the same way prioritizing feature requests does.

How does MoSCoW compare to RICE and Kano?

| Method | What it optimizes | Best for | Weakness | | --- | --- | --- | --- | | MoSCoW | Agreement on scope | Fixed deadlines and mixed stakeholders | No numbers, easy to game | | RICE | A ranked order | Sorting a long backlog of 50 plus items | False precision from guessed inputs | | Kano | Delight versus expectation | Deciding what to build and how to position it | Needs survey data to be useful |

The three work well in sequence. Use feature voting and idea management to gather candidates, RICE or Kano to rank them, and MoSCoW to agree what the next release can actually hold. Skipping straight to MoSCoW without ranking input is how teams end up negotiating opinions.

When should you not use MoSCoW?

Skip it when you need a strict order for a long list, because MoSCoW produces buckets and never a sequence. Skip it when nobody owns the release date, since the method leans on a deadline to make trade offs real. And skip it when the real question is whether a feature will delight users or simply be expected, which is a Kano question with survey data behind it. MoSCoW is strongest at the point where scope must be frozen: a launch date, a migration, a compliance deadline, a beta with a fixed group of users.

How does MoSCoW fit a feedback driven roadmap?

Treat MoSCoW as the last step, not the first. Gather raw input through a feedback widget in your app and public voting, let users rank the pain for you, then score and sort. When an item lands in Won't have, say so where people can see it and explain the reason, the way saying no to feature requests recommends, then keep the conversation open for the next cycle. The Won't column is the cheapest trust you can build with users, because most teams simply go quiet and let hope do the work of a decision. Publish the outcome on the roadmap you communicate, revisit it on the date you set, and the next session starts with evidence instead of a fresh argument.

Frequently Asked Questions

1. How long should a MoSCoW session take? For a single release, 60 to 90 minutes is normal once the candidate list exists. Prepare the list before the meeting, otherwise the first hour is spent listing work instead of deciding on it.
2. Who should be in the room? One owner who can agree scope, plus the people who will build it and whoever brings customer evidence. Everyone else gets the written outcome afterwards.
3. Is MoSCoW agile or waterfall? Neither. It came from rapid application development and fits any cycle with a fixed finish line, which is why agile teams still use it to freeze a sprint or a release.
4. What if a stakeholder refuses to demote their Must? Ask what to remove instead, and put both items on the same release date. The capacity cap ends the argument, because scope can grow only if something else leaves.
5. How often should you re run MoSCoW? Every cycle, or whenever the date or the team size changes. Treating last quarter's Must list as permanent is how a backlog stops reflecting reality.

A Must list is a promise, and every promise has a price in capacity. Create a free board on Inputly to collect feature votes, see what users ask for most, and give your next MoSCoW session real evidence to sort.