MoSCoW Prioritisation Method in Agile

Backlog prioritization is essential. Successful businesses know to prioritize based on business value over effort. The items that are on the top of the backlog must always be the ones that bring the highest business value with the minimum of the effort. It is a golden rule in Agile that no Product Owner should compromise.

Backlog prioritization is not an easy task. While coaching the Product Owners, I can see that sometimes it is tough to define the business value and order the backlog items based on the most profitable ones.

How might we prioritize without investing a significant amount of effort into it? The solution I recommend and that is working very well is the MoSCoW method when the Product Owner uses the four categories below to sort the product backlog:

#1. Must-have — urgent items, we know we want to do them, they bring important customer value. The Product Owners will add to this category the most critical and urgent user stories. Here you can include legal requirements, core functionalities, safety-related functionalities.

#2. Should Have — items that are important, but the effort of implementing them is considerable, or items that the Product Owner is not sure of their necessity, or things still need clarifications. These are functionalities

#3. Could Have — ideas that could add customer value to the future, row ideas that need to mature.

#4. Won’t have this time — items that are discarded for the time being, but not completely. With time, the Product Owner might consider upgrading the category of these backlog items.

Do the user stories need to be ready when being assigned to any of the MoSCoW categories?

No. They are used to sort the user stories before being assigned to a sprint. The Product Owner will take the user stories from the top of the must-have list and schedule it for the upcoming sprint. The user stories will follow the usual refinement process of the scrum team.

How do I assign the user stories from these categories to sprint?

You always start with the must-have. When the must-have is empty, you reevaluate. Ideally, you never pull into a sprint, items from a category inferior to must-have.

Should I decide in which category any user story should be?

If you cannot decide, most probably, it means it is not in the Must-Have category, or it shouldn’t be in any category at all. The best will be to put it in the backlog — a 5th category. Usually, in the product backlog, you’ll have user stories that aren’t filtered yet, or you should not look to them for the moment.

What do I put in the “Won’t have this time” category?

The primary skill as a Product Owner (PO) is to learn to say no. That can be very hard sometimes. But the MoSCoW method is convenient in helping the POs to tell “no”: they add the user stories initially in “Could Do”, and with the time, it goes into “Won’t Do this time” and out of the backlog completely. It helps to track the things that we give up for a reason or another.

Must do? — evaluated on each major release

I met product owners who loved so much this method that they were using it as a time horizon:

• must have — first next major release
• should have — second next major release. After the first release was live, the backlog items from this category become must-have
• could have — third next major release. After the go-live of the first release, the backlog items from this category become should have after being evaluated.
• won’t have this time — descoped

It was a straightforward way to show to the management where we are in terms of the scope for the next release — the fewer items, the better. But it also gives the big picture of what will come next and the opportunity of reprioritizing if needed.

How many items should I have in each category?

These are working categories. They need to be dynamic. You should have items for a timespan of a maximum of 2–3 months. More than that will make it very hard to manage the categories.

My organization uses the Scaled Agile Framework, how does the MoSCoW method fit into it?

The MoSCoW method is handy while planning your future Program Increments. If you are using SAFe, I recommend you use MoSCoW in 3 steps:

1. Features planning. As a Product Owner, you’ll first assign the features to any of these categories. You’ll take the Must-have features and split them into user stories.
2. User story planning. As a Product Owner, you first define the user stories of your futures planned for the next Program Increment. The next step you do as a PO is to assign each user story to one of the categories: Must Have, Should Have, Can Have, Won’t have this time. All the user stories from the group Won’t have this time are removed from the feature, if the feature contains user stories in the other categories. When implementing SAFe, it is crucial to finish the features during the Program Increment.
3. Program Increment Planning Meeting. While planning the next 4–5 sprints, the team will look into the categories of the user stories. The scrum team analysis the user stories one more time. The results are: the objectives link to the user stories in the must-have category, the user stories related to the uncommitted goals should be in the group of should have. The can have user stories, will be the ones the team wants to innovate on during the innovation and planning sprint. The user stories remaining in the “Won’t do this time” will be removed from the scope and removed from the features planned for the PI. At the end of the PI Planning Meeting, the scrum team has assigned all the user stories to sprints, and the four categories are empty, ready for the planning of the next Program Increment.

How do I use these categories in the project management tool?

If you use Jira/Asana, Team Foundation Server, you’ll continue to have your sprints on top of the backlog as usual. Between your top sprints and the Backlog section, you’ll create four sprints in this order of importance: Must Have, Should Have, Could Have, Can Have. Under these sprints, you’ll continue to have your backlog category.