MoSCoW Prioritisation for an App Release, Step by Step

Most prioritisation frameworks rank a backlog. MoSCoW does something different: it decides what goes into one release with a fixed date and a fixed team. That makes it the framework of choice when the date will not move, such as a seasonal launch, a conference demo or an App Store feature slot, and the question is what you can promise to deliver by then.

This guide works through a release for Trailmate, a fictional hiking app. For how MoSCoW sits alongside scoring frameworks, see the overview of prioritisation frameworks.

The short version

• Four groups: Must have, Should have, Could have, and Won't have this time.
• Start from the release goal, not the backlog. A Must have is something without which the release does not meet its goal.
• Keep Must haves to about 60% of the effort. The Could haves are your contingency.
• Votes and revenue settle arguments about Should and Could. They do not decide what is a Must.

Where MoSCoW comes from

MoSCoW is a core part of the DSDM agile method. The lower-case letters are there to make the acronym pronounceable. The Agile Business Consortium's guidance on MoSCoW is the reference for the definitions and the effort rule used here.

The four groups

Must have

The release has no point without it. If a Must have is missing, the release should not go out. DSDM calls this set the Minimum Usable SubseT, which is a good test: would anyone use the release without this?

Should have

Important, and painful to leave out, but the release still works without it, perhaps with a workaround.

Could have

Wanted, with less impact if it slips. These are the items you drop when a Must have runs late, and that is their job.

Won't have this time

Agreed to be out of this release. Writing them down is what stops them creeping back in during week six.

The 60% rule

The Agile Business Consortium recommends keeping Must haves to no more than about 60% of the total effort, and keeping around 20% as Could haves. The reasoning is simple. Estimates are wrong, and the gap between them and reality has to land somewhere. If everything is a Must, a late item breaks the release. If 40% of the work is not a Must, a late item costs you a Could have.

Note that the rule is about effort, not a count of items. Three small Must haves and one huge Could have is not a balanced release.

A worked release

Trailmate is planning a spring release, timed for the start of the hiking season. Two developers have twelve weeks, so the release has 24 developer-weeks. The goal is one sentence: Trailmate works on the trail when there is no signal.

The backlog, with the votes and monthly recurring revenue (MRR) behind each request:

Step 1: find the Must have, and check it against 60%

Offline maps is clearly the Must have for this goal. But all of it is 16 weeks, which is 67% of the release on its own. Over the line before anything else is added.

So split it. Offline maps for saved trails, where a hiker saves a route and its map before setting out, is 12 weeks. Downloading whole regions is a further 4. Saved trails meets the goal. Regions are a nice extra. The Must have is now 12 of 24 weeks, which is 50%.

Step 2: sort the rest using votes and revenue

With the Must fixed, the remaining requests compete for the other 12 weeks. This is where the numbers help.

• Trail difficulty filter has the second-largest revenue behind it, and its voters pay more than average. It does not serve the offline goal directly, but hikers choosing a route before losing signal will use it. Should have.
• Elevation profile has fewer votes, but its voters pay about as much as the filter's. It is useful offline, as it sits with the saved route. Could have.
• Share a hike is cheap and popular with free users. Could have.
• Trail notes is eight weeks of work for the smallest group of voters and the least revenue. Won't have this time.
• Offline regions, split off in step 1, is also Won't have this time.

Step 3: check the balance

Must haves are at 50%, under the 60% line. Could haves are at 25%, close to the recommended contingency. If offline maps runs three weeks late, Trailmate drops sharing a hike and still releases on time with the goal met.

Settling arguments with data

MoSCoW meetings stall when someone insists their favourite is a Must. Two questions help.

"Does the release fail its goal without it?" This is the test for a Must, and votes cannot answer it. A request with 500 votes can still be a Could have if it has nothing to do with this release.

"Who is asking?" For Should and Could, votes and revenue are the tie-breakers. A vocal request on a support thread with a handful of votes and little revenue behind it does not outrank a quieter request that your paying users keep voting for. Trail notes has passionate fans. It also has the least revenue behind it of anything on the list.

Won't have this time is not Rejected

This is the distinction teams most often get wrong. "Won't have this time" means not in this release. It does not mean never. Leave those requests open, and keep collecting votes on them, because the next release will need that evidence.

Keep "no" for the requests you will genuinely never build, and say so with a reason. Users accept a clear "not now" and an honest "no". What they resent is silence.

A simple mapping to request statuses:

• Must have and Should have: Approved, then In Progress as work starts.
• Could have: Approved, with the understanding that it may slip.
• Won't have this time: leave as Pending, so votes keep coming in.
• Never: Rejected, with a reason.

Common mistakes

• Starting from the backlog. Without a release goal, everything popular becomes a Must.
• Counting items, not effort. The 60% rule is about weeks of work.
• Never dropping a Could. If no Could have is ever cut, they were Must haves in disguise, and your contingency was fake.
• Using MoSCoW to rank a whole backlog. It sorts one release. To rank the backlog behind it, use RICE or the impact/effort matrix.

How FeedbackKit fits in

FeedbackKit records the two numbers that settle Should and Could arguments. Users vote and comment on requests inside your app through the Swift SDK, and a new request starts with its submitter's vote. On every plan, your app passes each user's MRR through the SDK, and in the native admin apps for iPhone, iPad and Mac requests can be sorted by the total MRR of the users behind them. You can also manage requests from the new web dashboard.

The statuses match the mapping above: Pending, Approved, In Progress, TestFlight, Completed and Rejected. A Pending request keeps collecting votes for the next release, while voting stops at Completed and Rejected. A Rejected request can carry a reason, and the person who submitted it can be emailed when its status changes. On Pro and up, an approved Must have can go to an issue tracker such as GitHub or Linear (see integrations and pricing).

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

A fixed date forces choices, and MoSCoW makes them visible. To bring your users' votes and revenue into the room when you make them, start free.