MoSCoW prioritization, with one release worked through request by request

MoSCoW prioritization sorts everything you could build into four buckets: Must have, Should have, Could have and Won't have this time. It is one of the most common ways to decide what goes into a release with a fixed date, and you will also see it called the MoSCoW method, MoSCoW analysis or the MoSCoW technique.

Most guides stop at the four definitions. This one takes the rules from their source, then sorts twelve feature requests for one release, including the mistake nearly every team makes on the first pass. Plant Diary is a made-up app for the example.

The short answer

Give every item one of four labels. Must have is anything without which the release makes no sense. Should have is important but survivable with a workaround. Could have is nice to have and the first thing you drop when time runs out. Won't have this time is explicitly out of this release. Then check the effort: DSDM, the agile framework that made MoSCoW popular, recommends that Must Haves take no more than 60% of the work and that Could Haves make up about 20%.

Where MoSCoW comes from

According to TechTarget, "Software development expert Dai Clegg created the MoSCoW method while working at Oracle". It spread through DSDM, an agile framework now maintained by the Agile Business Consortium, whose handbook still has the clearest rules. The two lowercase o's mean nothing. They only make the acronym pronounceable.

DSDM even reads MUST as a backronym:

"These provide the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver."

The four buckets

Must have

The release fails without it. DSDM's test is one question: "what happens if this requirement is not met?" If the honest answer is that you would cancel or postpone the release, it is a Must. Its other signs are "Not legal without it", "Unsafe without it" and "Cannot deliver a viable solution without it". And the escape hatch is written right into the rule:

"If there is some way around it, even if it is a manual and painful workaround, then it is a Should Have or a Could Have requirement."

Should have

DSDM defines these as "Important but not vital" and "May be painful to leave out, but the solution is still viable". Users will notice and some will complain, but the release still does its job.

Could have

"Wanted or desirable but less important". Could Haves are your safety margin. When the deadline is at risk, they go first, which is exactly why you want some in every release.

Won't have this time

The bucket teams skip, and the one that saves the most arguments. Writing down what you are not doing ends the discussion for this release, and DSDM names the reason: "This avoids them being informally reintroduced at a later date." The words "this time" matter. A Won't is a decision about this release, not a verdict on the idea.

A worked example: one release, twelve requests

Plant Diary is planning version 2.0. One developer has eight weeks, so 40 days of work, and the date is fixed: the release has to be out before spring, when people buy new plants. On the table are eleven feature requests from the app's feedback board, each with its vote count, plus one bug from support. Every item has a rough estimate in days.

The first pass, where everything is a Must

The first sort went the way it usually goes: everything with more than 20 votes became a Must, plus the bug. That made eight Musts and 70 days of guaranteed work for a 40 day release. At that point MoSCoW is just a wish list with labels, because there is nothing left to drop when time runs out.

The second pass, with the cancel test

Asked properly, "would we cancel 2.0 without it?" leaves three Musts. The bug, because reminders are the app's one job. Custom watering intervals, the most requested item and the release headline. And sync across devices, which was announced as the other half of 2.0. Everything else has a workaround, even the widget with 51 votes.

Between Should and Could, DSDM suggests weighing how many people a gap would hurt:

"One way of differentiating a Should Have requirement from a Could Have is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected."

Vote counts are a direct measure of "numbers of people affected", so the split falls out of the board: the widget, fertilizer reminders and dark mode are Shoulds, while the photo diary, the CSV export and the German translation are Coulds. Three requests land in Won't this time, including plant identification by photo with 33 votes. It has more demand than any Could, but at 20 days it would eat half the release on its own.

Then check the effort

Must Haves now take 22 of the 40 days, which is 55%. The Shoulds take 10 days and the Coulds 8, so 20% of the release is contingency, right where DSDM wants it. The three Won'ts don't count toward the 40 days at all.

"The safe percentage of Must Have requirements, in order to be confident of project success, is not to exceed 60% Must Have effort."

If the dark mode estimate turns out wrong halfway through, the plan already says what happens: the Coulds go first, and the three Musts still ship on time.

Common MoSCoW mistakes

• Everything is a Must. The first pass above. Without the cancel test and the 60% cap, the labels change nothing about what actually ships.
• No effort numbers. Rough days are enough, but without them you can't check the cap, and the Could pool is a guess.
• Arguing Should versus Could item by item. DSDM recommends agreeing the criteria first, such as a vote count or the number of paying customers affected, and notes that "Ideally this agreement is reached before the requirements are captured."
• Treating Won't as never. It is a decision for this release. Keep the list and start the next planning round from it.
• Sorting once and never again. New requests arrive and estimates slip. DSDM says priorities "should be reviewed at the end of each Timebox and each Project Increment", which for most teams means every sprint or release.

A MoSCoW template you can copy

A spreadsheet with five columns is all you need. Fill it in this order:

Then two checks: the Must days add up to no more than 60% of the days you have, and the Coulds add up to about 20%. If the Musts are over, one of them isn't really a Must.

Where the votes come from

The example works because every request came with a vote count. Without one, "numbers of people affected" is a guess, and the loudest person in the room decides what is a Should. A feature request board collects those numbers for you: users post ideas, vote on each other's, and the count is there when you plan. WishKit does that for apps and websites, and the steps of collecting requests are in how to collect and prioritize feature requests.

Votes don't make Musts, though. A request can have 33 votes and still be a Won't this time, and a bug nobody voted on can be the most important Must. The cancel test decides what is a Must. The votes settle everything below it. If you need a strict order rather than buckets, RICE prioritization turns the same votes into a score. To tell a basic people expect from a nice extra, the Kano model asks your users directly. All five frameworks are compared on this same list in the guide to feature prioritization.

Frequently asked questions