MoSCoW Priority Process

The MoSCoW process is a simple way to sort the User Stories that form the Product Backlog into a priority order.

MoSCoW stands for:

Must have

Should have

Could have

Won’t have

Must Haves are User Stories that must be included to create the MVP (Minimum Viable Product). Must Haves form the core of the scope of work that will need to be delivered.

Should Haves are User Stories that are not critical to the MVP, but are considered to be important and of a high value.

Could Haves are User Stories that are “nice to have.” They could potentially be included where time and resources are available. However, these User Stories will be the first to be removed from scope if the project is at risk of missing delivery of the MVP.

Won’t Haves are User Stories or Features that the Product Owner has requested but are not going to be built. These User Stories or Features may be built in the future but are not part of the scope of the current work.

Realistically, the User Stories need to be spread across the categories, so we avoid ending up with every User Story being listed as a Must Have.

Here’s my recommendation for the split values:

Must have — less than 80% of capacity,

Should have — No more than 20% of capacity,

Could have — No more than 10% of capacity,

Won’t have — as they won’t be build, there is no limit needed.

If you’re Must Haves exceed 80% of the total capacity, there will be no flexibility and little contingency if something goes wrong. There will most likely be some Must Haves that we decide not to be build. By having a number of User Stories in the Should and Could have categories, we create flexibility as we can choose to move them up in priority.

Agile embraces change and that means we can’t have every User Story prioritised as a Must Have.

But what do you do when the Product Owner thinks every User Story is a Must Have?

This is a problem I’ve faced a number of times. I’ve managed it by asking these questions:

1. User Story Mapping — what is the most basic path to success?

2. Value Mapping — which User Stories add the greatest value?

3. Feasibility — which User Stories are the simplest to build?

This allows the Product Owner to identify User Stories that are a nice to have, think Henry Ford when he decided to produce black model T Fords only in 1914. The greatest value to both Ford and customers was a simple, easy to build car. The customers understood that by having different colours for the Model T it would make it more expensive to build. The single colour was cheap in cost and very durable. It also simplified the production line.