Product Backlog Prioritization Techniques

Frank
Productific
Published in
4 min readMar 24, 2022

As a product owner you probably have little time and lots of challenges to fight with. In sleepless nights you ask yourself the following: What is my backlog? How do I best prioritize it? A list of required tasks and their optimal order of execution are desirable. This article introduces what a product backlog is all about and shows common prioritization techniques.

What are product backlog prioritization techniques?

Backlog prioritization techniques describe the approach to analyze and rank backlog items in order to decide which item to tackle first. Priorities are usually described by numbers to model the positive/negative impact of each item, making them comparable.

What is a product backlog?

A product backlog contains tasks to execute for managing a product. Traditionally it contains improvements and enhancements, things to build or refurbish. If you’re like most product owners you treat your product backlog like a dumping ground for everything that comes flying at you: customer requests, strategic enhancements, ops improvement and technical refactoring. Naturally, you (think you) know your big ticket items but there are so many backlog entries — things can be overlooked. A list of items helps managing product improvement tasks, like a product’s to-do list.

What is the best prioritization method?

Most backlog prioritization techniques fall into one of the two categories: they are ranking formulas or matrix approaches.

Ranking formulas help sorting a list of items, usually feature requests and other backlog entries.

Matrix approaches benchmark backlog items in two dimensions to make an informed decision on benefit and disadvantage.

Matrix approaches

Value vs Cost Matrix

Cost can be complexity, effort or similar measures for cost. Two flavors are typically used:

Value vs. Effort matrix and

Value vs. Complexity matrix

This matrix is popular because it maps out backlog items according to their cost-benefit relation, which is a standard business practice. It uses four quadrants to plot cost vs. benefit. Items with high value and low cost are usually tackled first because they give you the most ‘bang for the buck’. It is a very operative prioritization method, your product gets the most benefit for invested cost.

The Value v.s Complexity flavor additionaly considers risk, as a special type of cost measure. Likewise, there are flavors using other KPIs representing the cost aspect: Value vs. Risk, Value vs. Size, Value vs. Leadtime, Value vs. Dependencies. Ultimately, they all consider the cost that comes with building a certain feature.

Pros of Value vs Cost Matrix

  • Bread-and-butter approach, not considering it is a failure
  • Straight forward, simple and easy to understand
  • Drives towards easy wins

Cons of Value vs Cost Matrix

  • Tends to ignore long term, strategic aspects
  • Doesn’t work well when backlog items differ in orders of magnitude

Ranking formulas

ICE Scoring

ICE means Impact, Confidence, Ease. Impact quantifies the value of the backlog item in your key metric. This can be revenue, user count or similar. Confidence measures how certain you feel about the expected impact. Ease measures the difficulty of building the backlog item.

The owner or team scores the values of impact, confidence and ease on a scale of 1–10. The ICE score is calculated via Impact * Confidence * Ease simplifies the three dimensional scoring into one ranking.

Pros of ICE scoring

  • Good for ranking backlog items that compete for the same resources.
  • Good for ranking backlog items when you have a reasonably good understanding of the item on cost and result.

Cons of ICE scoring

  • Highly subjective, items are rated by owner/team. No real user feedback involved.
  • Not time stable, item ranking will largely depend on the timing of trending/pressuring topics.

RICE Scoring

RICE means Reach, Impact, Confidence, Effort. Reach quantifies the number of customers who will benefit from the item/feature. Ideally, this is based on actual feedback data. Impact estimates the benefit per user. Confidence measures how certain you feel about the estimated impact. Effort measures the cost of building this item, typically this is development cost. The RICE score calculates by Reach * Impact * Confidence / Effort.

Pros of RICE

  • Includes user feedback data
  • Includes individual users’ experience

Cons of RICE

  • Time-consuming estimates
  • Wear down when used repetitively
  • Highly subjective when not based on user feedback data

Kano model

This model was created by Japanese researcher Noiraki Kano in the 1980s. It models user satisfaction to prioritize product backlog items. With Kano, backlog items are scored on multiple criteria from a user/customer perspective: must-be, attractive, one-dimensional, indifferent and reverse. Must-be features are needed by customers for the product to function. One-dimensional features are important and desirable for customers. Attractive features add value and satisfaction. Indifferent features have little or no value. Reverse features have a negative impact on customers. Major challenge for the Kano model is the quality of scoring data, which is in reality usually generated by internal stakeholders instead of actual users.

Pros of Kano

  • User perspective first: ranks backlog items by their customer value

Cons of Kano

  • Ignores all non-user qualities like cost, risk and strategic fit
  • Highly subjective when not based on real user feedback data

We do recommend to keep it simple and use any sort of cost vs. benefit flavor as the main decision driver. Cost estimations are highly depending on the actual organization, usually this is cost of development including a risk compensation. The estimation of benefit should be based on actual market and user data, ideally with a feature voting or customer feedback channel.

Source: The original & up-to-date version of this article is available as “Product Backlog Prioritization Techniques” on the Productific’s product management blog.

Readers of this article may also be interested in “How to structure your product team”.

--

--

Frank
Productific

Writes about Product Strategy, Growth & Architecture. Creator of https://productific.com.