# MoSCoW Prioritization: Rules, Example and the 60% Limit

> MoSCoW prioritization sorts requirements into must have (the release fails without it), should have (important but can wait), could have (nice to have) and won't have this time (deliberately deferred). The rule that makes it work: must-haves should take no more than 60 percent of the estimated effort, leaving contingency for surprises.

- URL: https://go-projects.de/en/planning/moscow-prioritization/
- Language: en
- Updated: 2026-10-19
- Publisher: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

Put every requirement on a wall, ask a room of stakeholders which ones matter, and you'll watch the same thing happen every time. Almost everything becomes a must-have. Nobody wants to admit their item can wait, because "later" so often means "never".

MoSCoW deals with that through arithmetic, not persuasion. Dai Clegg developed the technique in 1994 for rapid application development, and it spread widely once the DSDM framework adopted it. The [Agile Business Consortium](https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html), which now maintains DSDM, gives one number that does most of the work: must-haves should take no more than 60 percent of estimated effort.

## The four categories, defined precisely

The labels sound obvious. Precision is what makes them useful.

| Category | Meaning | Example: online returns portal |
|---|---|---|
| Must have | Without it, the release fails: unusable, unlawful or unsafe. | Customer starts a return, prints a label |
| Should have | Important and painful to lack, but a workaround exists, even a manual one for a few weeks. | Automatic refund once the parcel is scanned |
| Could have | Desirable, improves the experience, costs a lot relative to value. Dropped first. | Choice of courier, return reason analytics |
| Won't have this time | Deliberately out of this release. Stays in the backlog. | Native mobile app |

"This time" carries more weight than it seems. It takes the heat out of the discussion, because no request disappears for good.

## Test questions for a genuine must-have

Before an item earns the top category, put it through these questions:

- Could we go live if exactly this feature were missing?
- Is there a workaround, however clumsy or manual?
- Would we break a law, a contract or a security requirement without it?
- Would our most important user group reject the system without it?

If the answer to the first two is yes, it isn't a must. Automated refunds in the table above are a classic case. Everyone wants them. For launch, a finance clerk processing a daily list of returned parcels is an acceptable stopgap, so the feature becomes a should.

## The 60 percent rule, with a worked example

Why 60 percent? Because early estimates are unreliable. Steve McConnell's cone of uncertainty shows that even after requirements are complete, actual effort can land anywhere from about a third lower to 50 percent higher than estimated. Fill 100 percent of the budget with must-haves and you have no buffer. Any slip then threatens the core of the release.

The rule applies to effort, not to the count of items. Ten small musts may cost less than one big one.

**Recommended effort split under MoSCoW**

| Share | % |
|---|---|
| Must have | 60 |
| Should have | 20 |
| Could have | 20 |

Must at most 60% and Could around 20% per the Agile Business Consortium. The Should share is the remainder and serves as a guide, not a fixed rule.

Here is how that plays out. Say the team estimates every requirement for the returns portal at 230 developer-days, and the budget covers 200.

**Example: returns portal with a 200 developer-day budget**

- Budget: 200 days
- Must ceiling (60%): 120 days
- Estimated must-have items: 141 days
- Overhang to downgrade: 21 days
- **Should plus could, maximum: 80 days**

Those 21 days are the real agenda of the workshop. Which must-have has a workaround? Here, the courier integration could start with one carrier instead of three, which might free up most of the overhang.

## Running a MoSCoW workshop

Half a day covers 40 to 80 requirements if they're estimated beforehand. Without estimates the 60 percent rule can't be applied, and the session turns into a debate of opinions. Our guide to [software estimation techniques](https://go-projects.de/en/estimates-and-budget/software-estimation-techniques/) explains how to get a quick range first.

1. Every requirement starts as won't have. Each one must earn its category.
2. Check must candidates against the test questions.
3. Add up the effort for the must group and compare it with 60 percent.
4. Downgrade until it fits.
5. Sort shoulds and coulds by value per unit of effort.
6. Record the result with a date and the names of the decision-makers.

Step one feels harsh. It flips the burden of proof and saves hours.

## Where MoSCoW goes wrong

The most common failure is a must share of 80 or 90 percent that gets waved through anyway. At that point the method is decoration. The board looks tidy, but it won't protect you when money runs short and nothing can move.

The second failure is categorising items without any user context. Requirements written as [user stories with a clear benefit](https://go-projects.de/en/planning/how-to-write-user-stories/) are easier to judge, because the "so that" clause shows what breaks without them. Write just "export" on a card and it can be argued into any bucket.

Third, the categories get quietly eroded during delivery. New requests land straight in must without anything moving out. Every new must needs a counter-entry: what drops down to make room? That's exactly what a disciplined [change request process](https://go-projects.de/en/running-the-project/change-request-process/) enforces.

## Limits of the method

MoSCoW says nothing about the order in which musts get built. Technical dependencies and risk decide that. Risky items, such as an unfamiliar third-party API, belong early in the plan even if they're no more valuable than other musts.

Categories also age. An item that was a should in March can become a must in June because of a regulatory change. Review the split at each release, or during backlog refinement if you run Scrum.

If you need a finer ranking, score items within each bucket using RICE or WSJF. For most mid-sized projects that's overkill.

## MoSCoW in contracts

On fixed-price work, the categories are worth real money. Suppose the contract commits the vendor to all musts, and to shoulds and coulds "within the agreed budget". That clause builds flexibility into the deal. See [fixed price vs time and materials](https://go-projects.de/en/estimates-and-budget/fixed-price-vs-time-and-materials/) for how such hybrid models work.

Your development partner can help put effort numbers on each item so the 60 percent line rests on data rather than gut feeling. [OnlineBuilders](https://onlinebuilders.biz/solutions/software-development) does this as part of its free initial technical consultation.

Next step: mark everything currently labelled must in your requirements list and add up the estimated effort. If the total is above 60 percent of your budget, you know what the next meeting is about.

## FAQ

### What do the letters in MoSCoW stand for?

Must have, Should have, Could have and Won't have this time. The two lowercase o's mean nothing; they just make the acronym pronounceable.

### Who decides what counts as a must-have?

The business owner of the budget, usually the product owner or client. Developers provide effort estimates and flag dependencies, but they don't decide on business value.

### Is MoSCoW an agile technique?

Yes. It was created for rapid application development and later adopted by the DSDM agile framework. You can apply it per sprint, per release or across a whole project.

### How is MoSCoW different from RICE or WSJF?

MoSCoW sorts items into four buckets and protects a budget buffer. RICE and WSJF produce a numeric score for ranking. Some teams use MoSCoW first and then rank items within each bucket with a score.

Photo: Ciell, CC BY-SA 4.0 (https://commons.wikimedia.org/wiki/File:Techstorm_posters_-_progress_day_1.jpg)