The Scrum Guide says that the Product Owner is responsible for “Ordering the items in the Product Backlog to best achieve goals and missions” and “Optimizing the value of the work the Development Team performs”.

Scrum allows Product Owners to select their own techniques for planning and prioritisation. So, how should a Scrum Product Owner go about prioritising the stories on their backlogs?

A common technique for prioritising requirements is the MoSCoW method. It was developed by Dai Clegg of Oracle UK Consulting, who then donated the idea to the Dynamic Systems Development Method (DSDM) Consortium.

DSDM Atern is an Agile method that explicitly describes MoSCoW as a prioritisation technique. MoSCoW is also described in the Business Analysis Body of Knowledge (BABOK).

So, if it’s in common use and described in several industry standards, is it a good choice?

As with most tools, there are situations where it’s a good fit, but it also has some flaws. So let’s take a look at the technique, some of the problems you can encounter when you use it and some recommendations for better prioritisation.

What is MoSCoW prioritisation?

MoSCoW is intended as an improvement over rating the importance of requirements as “High”, “Medium” and “Low”. Typically there isn’t a good understanding of those levels, so MoSCoW gives categories with explicit definitions:

Must Have

Requirements in this category form the Minimum Usable SubseT (MUST) of requirements. If the answer to the question “what happens if this requirement is not met?” is “cancel the project – there is no point in implementing a solution that does not meet this requirement” then it is a Must Have requirement. If that isn’t the answer, the requirement isn’t a Must.

A project is guaranteeing to deliver these requirements; DSDM recommends that there are at most 60% of requirements in this category.

Typically, you might define this for your project using some of:

• Cannot deliver on target date without this
• No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
• Not legal without it
• Unsafe without it
• Cannot deliver the Business Case without it

Should Have

• Important but not vital
• May be painful to leave out, but the solution is still viable
• May need some kind of workaround

Could Have

• Wanted or desirable but less important
• Less impact if left out (compared with a Should Have)

Won’t Have this time

• These are requirements which the project team has agreed it will not deliver. The reason for tracking them is to acknowledge that they have been asked for and to stop them being re-introduced at a later time.

To prioritise a backlog, a product owner can assign each item on the backlog to one of these four categories and then order by category. For example:

The problems with MoSCoW prioritisation

Let’s take a look at some of the problems you can encounter using MoSCoW.

1. Everything is a “Must”

It’s quite common for stakeholders to insist that the majority of items are “musts”. The DSDM definition is quite strong and the “if you can’t have it, we’ll cancel the project” criteria is a clear test. The guidance that at most 60% of requirements or stories should be “Musts” is helpful. DSDM also suggests that if everything is a “Must” it’s a sign of insufficient decomposition.

It requires a strong and skilful Product Owner to enforce the test and limit the “Musts” to be stories that are genuinely necessary. In my experience, I’ve seen several Product Owners frustrated about how their stakeholders insist on everything being a “Must” and the conversations around this topic are often heated and frustrating.

2. No differentiation inside categories

Although MoSCoW is an improvement over “high/medium/low” it is still a course-grained categorisation. If there are 15 Shoulds but we can’t do them all, then we need some other way to know which are more important than others.

3. Categorisation can come from hidden agendas or misunderstood goals

I’ve seen several situations where a Product Owner prioritised “must have” stories based on one stakeholder’s opinion only to discover, after implementation, that a more senior stakeholder was not at all interested in those stories and wanted something else instead.

This is a problem of stakeholder engagement and it can be managed. But what we’re seeing is that MoSCoW categories have a habit of being assigned based on personal opinion as opposed to being checked for alignment to some high-level goals or business case.

4. Re-prioritisation is painful

If something changes in the business drivers for the project, for example a move by a competitor or a shift in markets, then the categories of the entire backlog potentially need to be re-assessed, which could re-open a drawn-out debate.

How can we do better?

Although the intent of MoSCoW is that the priorities are explicit, in fact they are quite vague, except for “Must Have”. For example, DSDM’s suggested definitions for “Should have” are “Important but not vital” and “May be painful to leave out”. How do we know what is important / not important? How much pain is OK? Whose pain?

DSDM says: “the definitions of Must Have, Should Have, Could Have and Won’t Have need to be agreed with the business”. So one approach is to try to get those definitions so clear that they are unambiguous and you could test them. That’s not necessarily easy to do up-front.

The root cause of all the issues above is that the decision-making criteria are being hidden. The Product Owner, and potentially other stakeholders, just say that an item “Must” be done – they don’t explain why. They don’t explain the reasoning behind the decision.

Where I have seen MoSCoW used successfully it’s because it’s accompanied by exploration that leads to a common understanding of the business drivers and goals.

For example, if someone is insisting a story is a “must”, you could ask, with some genuine interest, “What happens if we release without that?” and explore the consequences. It could be that people might die or that the business risks being shut down or fined. It could be that there’s a security risk. Whatever the underlying reason, the interesting thing is to surface that reason and clarify it so everyone can use it as a decision-making criterion for future stories.

Having a common understanding amongst the stakeholders and the project team of the prioritisation criteria makes decisions run much smoother. So, what make good decision criteria?

DSDM says: “The best way to address prioritisation initially is with a quantified Business Case. … If a Business Case does not exist, the Business Sponsor and Business Visionary need to articulate the business drivers, preferably in a quantified form.”

If you have that business case or quantified business drivers, then they can be a powerful tool for guiding your decisions not just initially, but throughout the project.

The Scrum guide gives the Product Owner the responsibilities of “Ordering… the Product Backlog to best achieve goals and missions” and “Optimizing the value of the work…”. So the Product Owner’s role isn’t to accept MoSCoW categories, but to understand the goals, missions and value behind them.

Some recommendations

We’ve explored MoSCoW, seen some of its problems and discussed how successful use depends on clear definitions of the categories, plus additional conversations that are connecting prioritisation to business drivers.

So here are some recommendations:

• MoSCoW can be useful for a fast triage of many stories
  • Make sure the definition of “Must” as “Would cancel the project” is well-understood
  • Don’t let people get hung up on the other categories – just do it fast
• “Must” is a useful category for extracting important drivers and constraints
  • Ask “What would happen if we released without that?”
• If you’re using MoSCoW on an ongoing basis:
  • Define the categories as unambiguously as you can, so ideally you can test a requirement against the definition and reduce the need for debate
  • Constantly refer back to the category definitions when prioritising
  • Use any disagreement as an opportunity to improve the category definitions
• Start moving towards conversations that talk about the business drivers
  • List and keep referring to your particular business drivers in prioritisation meetings
  • Use any disagreements to clarify the business drivers
  • Start including the contribution to each business driver as part of an item’s definition, for example:
    

    Category	Name	is Revenue Generating	is Regulatory	is Security
    Must	Buy product	Y	N	N
    Must	Authenticate Users	N	Y	Y
    Should	Recommend other products	Y	N	N

If you want to move conversations more towards business value and drivers, then you should find my article on Uncovering Agile Business Value useful. And if you want a sophisticated prioritisation tool based on business drivers, then take a look at my article Fast, Transparent Agile Prioritisation using Business Value.

What Next?

• To learn this in-depth, look at our training and our coaching
• To benefit from the approach in your organisation, please Contact Us
• Let us know what you think by commenting below