4 Backlog Prioritization Techniques for Winning Products
As a product owner, how do you know that what you’re planning to do next is best for your product, company, and customers?
The answer is never cut and dry.
In the best cases, you can attribute a direct business value to an item (for example, accounts you’ll win if implemented). In reality, however, correctly quantifying the business value for an item is nearly impossible.
But there are several commonly used techniques to prioritize your product backlog. These techniques can give your team focus, your customers value, and your company a winning product.
During prioritization, product owners must apply their understanding of customer and business needs. Some like to stack rank every item from 1 to n instead. Others prefer a bucket approach (see Kano and MoSCoW models below). A bucket approach can be easier, especially if you’re starting from scratch with a large backlog. After tasks are prioritized into their respective buckets, you can refine them as much as you want.
(For more on the refinement process, see our post on successful backlog grooming.)
Let’s look at a few concrete ways you can get your priorities in order. Remember, you needn’t get it exactly right from the beginning. The key is to actually do it — and with a systematic approach that you can gradually improve upon.
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 very high priority.
- It is often more accurate, 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 to provide absolute values (such as “very high priority”).
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. There are a variety of versions of the Kano model. The original, however, classifies 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, 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, happy when they’re not. For example, you might implement high-security features requiring an extra step to login. 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 time comes to prioritize what goes into a release, it’s a good practice to pick one from each of the important categories above.
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 that delivery is not guaranteed.
Should Have — Should Have features are important, but notabsolutely 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 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 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 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.
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 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 cost of delay for any given feature can be challenging. Those who are good at it try to consider how 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. In fact, 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 against cost of implementation, will often give you a good idea of what should be done first.
Bringing It All Together
If backlog items are turning into a large and unwieldy queue, it’s time to prioritize. As pointed out, there are numerous ways to so. No, prioritization is not a perfect science, but the important thing is to get started. With some experience, you’ll discover which method or combination of methods work best for your product, team, and market.