Blog
June 11, 2018
Your product backlog is important. It's filled with items you need to address... at some point.
But how do you know which backlog item to work on next? Learn more about product backlog prioritization.
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:
We will explain and compare each in this article.
Back to top4 Product Backlog Prioritization Techniques
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.
Technique 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 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”).
🔎 LOOKING FOR SOMETHING MORE ROBUST? DOWNLOAD 6 TIPS FOR A LEANER BACKLOG >>
Technique 2: 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. 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.
READ >> BEST PRACTICES FOR PRODUCT BACKLOG GROOMING
Technique 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 that delivery is not guaranteed.
Should Have — Should Have features are important, but not absolutely 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.
▶️ LEARN >> WATCH HOW TO MASTER YOUR BACKLOG WITH HELIX PLAN
Technique 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 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.
Back to topBringing 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.
Prioritize Your Backlog in Helix Plan
Learn more about Helix Plan (formerly Hansoft), the better backlog management tool that offers all of these prioritization methods (and many more) out of the box, so you can prioritize your way to success.