Which Prioritization Method is Right for Me?

Imagine this scenario: you’ve created your initial product backlog. The requirements on your backlog have been broken down just enough, not too much, but just enough to be able to prioritize delivery of features to the customer. How do you prioritize, who does it, and what options do you have?

Firstly, it is important to have a vision. In fact, you should create the product backlog with this vision in mind. The vision helps communicate to everyone involved what the outcome of the product should be.

The Product Owner or Customer role is responsible for prioritizing a Product Backlog, but they cannot do it alone. The Product Owner will need to communicate with all stakeholders to understand which requirements are important to each one of them. The Product Owner will also need to communicate with the Development team to understand dependencies and the effort that a requirement would take to deliver.

Too often, a more senior person in an organization can make their feelings known and adversely affect prioritization. This anti-pattern is sometimes known as the HIPPO (Highest Paid Person’s Opinion), or the LVD (Loudest Voice Dominates).

To remove the HIPPO & LVD effect there are tools we can use. As with most Agile techniques and Practices, there is not one right answer. You need to choose the appropriate method or combination of methods to work in your context.

Let’s look at some of these prioritization techniques.

Simple prioritization

A simple prioritization technique could be comparing cost versus benefit, or, in Agile terms, Effort versus Value.

Simply size the requirements’ effort, and the requirements’ value. There are many sizing techniques you could use. Some examples are: High/Medium/Low, T-Shirt Sizing, and Story Pointing.

After you have employed the relative sizing technique of your choice, you can map the results by using a simple graph.

The graph will then visualize which items to do first, next, and last.

You may also consider other dimensions, like Importance, Urgency, Cost or Risk. For example, you might want to consider what is ‘Urgent’, how ‘Important’ it is, or how much something costs against how much ‘Risk’ it reduces.

MoSCoW

MoSCoW prioritization is often used and often abused. MoSCoW comes from Must have, Should Have, Could Have, Won’t have this time.

What these categories mean, in more detail:

Must have – without this requirement the system cannot go live.

Should have – we could go live without this requirement, but there might be a costly work around or high loss of value.

Could have – we could go live without this requirement, there might be a small workaround or small loss of value.

Won’t have this time – we do not plan to deliver this requirement in the current timeframe.

The abuse of MoSCoW consists of the fact that people often prioritize everything as a Must. The guideline is there should be a maximum of 60% Must in a Backlog, and a minimum of 20% Could. This gives the backlog a healthy balance of priorities and gives the team the necessary flexibility in requirements.

Also worth noting is that MoSCoW is only relevant to the timeframe of the Backlog. For example, a requirement on the Product Backlog may be a must. The same requirement on a Sprint Backlog could be prioritized for the Sprint as a Should. It is still a Must for the whole product, but only a Should for the sprint.

As MoSCoW is timeframe specific, it is often used for Agile Projects, or where there is a fixed deadline. So it could also be used for managing the requirements for a specific release of a product.

Kano Analysis

Kano Analysis comes from Noriaki Kano’s work in 1984. He created a model that identifies five different categories which you might consider when prioritizing your requirements.

The five different categories are:

1. Attractive quality – Surprise and delighters

• Valuable to users but maybe not to purchasers, if they are different
• Today’s Attractor is tomorrow’s Must-be.

2. One-dimensional quality – more is better

• Needs to be quantified – ‘minimum’ and ‘maximum’ are too vague
• What about diminishing returns?

3. Indifferent quality – customer doesn’t care

• So why bother?

4. Must-be quality – expected by the customer

• Minimum usable subset, minimum marketable feature set.

5. Reverse quality – Some customers prefer the reverse

• Not all users are the same e.g. too many features confuse some people.

I like to use elements of a mobile phone as an example to help me think about these different qualities:

• Attractive quality: A bigger screen, more apps
• One-dimensional quality: Faster data connections
• Indifferent quality: The make of the processor
• Must-be quality: It must make phone calls
• Reverse quality: Some customers want a phone that is just a phone and is simple to use.

The Kano analysis is a great tool for thinking about which features a customer considers important to the quality of a product.

Cost of Delay (CoD)

When we have established the value of a requirement we can identify how much the delay in delivering it costs us. For example, if a feature could earn $5,000 per week, and it remains on the product backlog for 10 weeks, then over 10 weeks the cost of delaying delivery is $50,000.

This is great if all of our features take the same effort or time to deliver.

So what do we do if two features have the same Cost of Delay, but one takes longer to deliver than the other? The answer is simple: we would do the thing that takes the least time first, so that we start to earn the value sooner.

The identification of Cost of Delay can be very complex. You could use very complex financial analysis and mathematics, or you could simplify things by using a relative sizing technique such as Story Points for value. There are pros and cons of both. I say: use whichever works for you.

But, of course, in reality our Product Backlogs will be made up of items that are all of differing Cost of Delay and of differing effort. How do we deal with this?

The technique we use implies taking the Cost of Delay and dividing it by the duration. This can be called Cost of Delay Divided by Duration (CD3), or Weighted Shortest Job First (WSJF).

CoD and CD3/WSJF are great techniques for prioritizing, driven by the actual economics of the requirements and their delivery. By using the real economics of the situation, you can have a really informed discussion with those ‘Hippos’.

What’s the key takeaway?

As you have read above, there are a few techniques you could use, and there are probably more out there too. The key takeaway is that you have several options at hand, and you need to pick the right technique or combination of techniques for your context, to get the right result, whilst being as simple or as sophisticated as you need.

Let me tell you something though. After a good conversation, sometimes there is just an obvious or sensible sequence to do stuff…

What prioritization method do you use?