How to Prioritize a Product Backlog? Lets discuss some techniques

How do you know which product backlog item to work on next? 

Product backlog prioritization is not an exact science. What works for someone else may not work for you at all.

Often organizations experiment with different techniques and adapt what works for them.

Most common prioritization techniques are as follow:

• Stack Ranking
• Kano Model
• MoSCoW Method
• Cost of Delay
• Smallest Effort First

Stack Ranking:

Comparing single item to just another single item and making decision about it's priority is called stack ranking. When you stack rank, you consider each backlog item and place it in order of priority. You start with one, then two, then three, and continue to n, the total number of items in your backlog. When you’re faced with a large, unordered backlog, it’s hard to say if item #6 is in the right spot. But you can probably figure out if #6 should be higher or lower than item #7. Usually stack ranking works well for maintaining a product backlog. It also helps in situation where everything is important.

Kano Model:

The Kano model was developed in the 1980s by Professor Noriaki Kano. Under the Kano Model, features are categorized according to needs and expectations of customers. The original model classifies items using five thresholds as below:

• Must-Be: These are expected by your customers. They are features that will not WOW them. They must be included in your product, and are often taken for granted.
• Attractive: These make users happy when they’re there, but don’t disappoint them when they’re not.
• One-Dimensional: These are features that make users happy when they’re there, unhappy when they’re not.
• Indifferent: These have no impact on customer satisfaction levels. There is no direct value to the customer. More organized / Readable code, Comments...
• Reverse: These make users unhappy when they’re there, happy when they’re not. Example some extra steps in login/registering/subscribing...

MoSCoW Method:

The MoSCoW model was created by pioneering data scientist Dai Clegg. The MoSCoW model takes its name from the letters that make up its criteria as described below:

• Must Have: If unable to release without including, then it’s a Must Have.
• Should Have: Should Have features are important, but not absolutely vital for release. They don’t affect minimum viability of your product.
• Could Have: Could Have items are those that are wanted or desirable. 
• Won’t Have: Won’t Have user stories are those in which everyone has agreed not to deliver this time around. Remove them or keep in the backlog for later.

Cost of Delay:

“If you are going to quantify one thing, quantify the cost of delay,” Donald Reinertsen.

Keep in mind that cost of delay is not necessarily measured in terms of dollars. There are many ways to assess value and cost. Reputation or story points are two examples.

There are some standards to measure cost of delay described as below:

• Linear: For every day we do not deliver, we lose some money.
• Fixed date: If we don’t deliver by a certain date, it’s too late.
• Intangible: Can delay for now at min cost but can become costly over time.
• Expedite: It must be done immediately or the cost of delay will grow radically.

Smallest Effort First:

If you’ve have 15 minutes to pick few tasks to finish, you’ve used the smallest effort first prioritization technique. 

On a team level, this can be more complex as you’ll need to estimate together how much effort different stories take. After you are all done with that, you simply sort them from lowest to highest effort. 

This approach works well if you:

• Have a limited amount of time. 
• Want to get used to shipping fast. 
• Have a lot of bugs. 

Remember this approach does not consider value at all. This means you may find you’re delaying high-value items for a long time, because they were never the smallest effort in some cases.