Backlog Prioritization Techniques

How do You Prioritize a Product Backlog?
Product backlog prioritization is not an exact science. What works for someone else may not work for you. The best way to approach it is through one of 4 techniques:   1. Stack Ranking   2. Kano Model   3. MoSCoW Method   4. Cost of Delay

1: 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.

There are two, dare I say, beautiful things about stack ranking:
There can only be one number one. So, you will avoid a common (and, frankly, stressful) product pitfall where everything becomes a very high priority.It is often more accurate, and less confusing. You prioritize each item relative to all other items, which makes it simplifies the process and makes it clearer. This is often a more accurate and easier way to prioritize than providing absolute values (such as “very high priority”).

2: Kano Model
The Kano model was developed in the 1980s by Professor Noriaki Kano. Under the Kano Model, features are categorized according to the needs and expectations of customers. There are a variety of versions of the Kano model. The original, however, classify items using five thresholds: Must-be, Attractive, One-Dimensional, Indifferent, and Reverse.

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, and unhappy when they’re not.
Indifferent — These have no impact on customer satisfaction levels. For example, refactoring parts of your code so that it is easier to read and understand. There is no direct value to the customer, but it will make it easier for you to maintain in the future.

Reverse — These make users unhappy when they’re there, and happy when they’re not. For example, you might implement high-security features requiring an extra step to log in. However, if customers do not value enhanced security, they will become dissatisfied with the extra step.

Why Use the Kano Model?The Kano model is tremendously useful in organizations that tend to only do Must-Be features. But, to succeed in the marketplace, you also need to deliver attractive and one-dimensional features. So, when the time comes to prioritize what goes into a release, it’s a good practice to pick one from each of the important categories above.

3: MoSCoW Method
The MoSCoW model, credited to pioneering data scientist Dai Clegg, has roots in Agile software development. The MoSCoW model has nothing to do with Russia’s capital. Rather, it takes its name from the letters that make up its criteria: Must Have, Should Have, Could Have, and Won’t Have.

Must-Have — If you would have to cancel your release if you couldn’t include it, then it’s a Must Have. 
Must-Have user stories are those that you guarantee to deliver because you can’t deliver without, or it would be illegal or unsafe without. If there’s any way to deliver without it — a workaround, for example — then it should be downgraded to Should Have or Could Have. That doesn’t mean it won’t be delivered. It means that delivery is not guaranteed.

Should Have — Should Have features are important but not vital to the success of your release. They can be painful to leave out and may have an impact on your product, but they don’t affect the minimum viability of your product.
Could Have — Could Have items are those that are wanted or desirable but are less important than a Should Have item. Leaving them out will cause less pain than a Should Have item.

Won’t Have— Won’t Have user stories are those in which everyone has agreed not to deliver this time around. You may keep it in the backlog for later, if or when it becomes necessary to do so.

Kano Model Versus MoSCoW Model — The Difference
The Kano Model and the MoSCoW model are similar in that they provide buckets sortable by a degree of need. They are not, however, interchangeable. A “must-have” in the MoSCoW model is not equal to a “must be” in the Kano model.
The MoSCoW category often is the priority and, since it’s owned by the product owner, has a product-driven perspective. The Kano model categorization, on the other hand, based more on input from product management, sales, competition analysis, etcetera, has a market-driven perspective.

Combining these two methods, therefore, can be very valuable for Agile teams. By delivering a combination of “must-be”, “attractive”, and “one-dimensional” features, along with “must-haves” according to MoSCoW, you ensure your product has a good mix of customer-friendly, market-ready features.

4: Cost of Delay
“If you are going to quantify one thing, quantify the cost of delay,” says lean thought leader Donald Reinertsen.
Despite that compelling maxim, most product development organizations today have little, if any, shared knowledge of the cost of delay for each feature.

To quantify the cost of delay is to answer the question: “What will be the cost per time unit if we delayed delivery?” You can then compare your answer with the estimate to deliver the feature with the highest cost of delay, and is cheapest to do, first. This is called Weighted Shortest Job First (WSJF) prioritization.

Keep in mind that the 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.

Quantifying the cost of delay for any given feature can be challenging. Those who are good at it try to consider how the cost of delay changes over time. They commonly use standards, such as the following.
Linear — For every day we do not deliver, we lose some money. A common example of a linear cost of delay is money lost due to competitors already having a feature that you don’t.

Fixed date — If we don’t deliver by a certain date, it’s too late. An example: let’s imagine you’re making New Year cards for 2019. If you don’t deliver them before the end of 2018, the cost of delay is very high. Delivering afterward, in January or February, makes no difference — it is too late!

Intangible — We can delay for now at minimal cost, but eventually it could become expensive. A good example is the cost of delay for fixing a few bugs or refactoring your code. You can skip today, but over time it will make other improvements more expensive and can cause the cost of delay to increase exponentially.

Expedite — It must be done immediately or the cost of delay will grow radically. An example of an expedite feature is a severe bug that renders your product useless to all your customers.

The cost of delay categorization, when compared to the cost of implementation, will often give you a good idea of what should be done first.