An Agile project only runs smoothly when the Backlog is in order. Smart software development teams know that a well-groomed and prioritized Backlog allows them to plan iterations well. In this way, they can communicate within the team and with stakeholders. 

First, let’s define our terms. What exactly do we mean by Product Backlog? The Product Backlog is a prioritized list of work a software development team needs to complete to finish the current Sprint. Priority items appear at the top of the list. The team sets their own pace, they tackle items from the Backlog as they have time to complete them.

Read more in Sprint Backlog vs Product Backlog to learn the main differences.

Why do teams prioritize their Backlogs? Why not just randomly complete tasks until they finish the Backlog? For a team to deliver their project, some items on the Backlog might rely on other items to function. Or the team might need to complete certain tasks first for the customers’ needs. Sometimes Product Owners might need certain tasks completed in order to show them to stakeholders.

How do you Prioritize a Backlog?

Below we have some tips to help you prioritize your Project Backlog.

1. Sort and categorize the items on the Backlog. Make a note of which items have high and low priority, and which bugs need fixing. The team should also label Backlog items (tasks, stories, epics) according to the amount of work required to complete them.

2. Tackle the high-priority tasks first, save less important tasks for later.

3. Score your Backlog items according to factors important to your team. Chose metrics like customer value, ROI (Return on Investment), or interdependencies.

4. Low-priority items can move to a separate list, making the Backlog list shorter and easier to understand. Teams can create a “new features” or “great ideas” list.

5. Refine and re-evaluate your Product Backlog. The Product Backlog lives and breathes, teams should regularly make sure the priority items still remain the most important.

6. Finally, once the team has prioritized their Product Backlog, begin at the top of the list and work down. Prioritization only works if the team actually follows up on their commitments.

Who should prioritize the Backlog?

Product Owners should prioritize the Backlog with input from the software development team and stakeholdlers. Product Owners should order the Backlog with an eye on which items need attention sooner and which items can wait.

Savvy Agile teams rely on many Backlog Prioritization techniques. Let’s take a look at the most useful ones.

1. RICE

RICE stands for Reach, Impact, Confidence, and Effort. When measuring Reach, teams look to quantify the number of customers who will use the feature benefit from the Backlog item. Whenever Possible, this number should come from actual data, not a guess. Impact asks the team to make an educated guess about how likely the feature in the Backlog will impact an individual user. Confidence measures the team’s confidence in their estimates. Effort measures the amount of work and time the team will need to devote to the Backlog item to complete it.

Pros of RICE

• Puts users at the center

• Relies on data and sold metrics

• Comprehensive

Cons of RICE

• Time-consuming

• Math-heavy

• Data-driven, without a lot of data teams might have to make many guesses

2. Opportunity scoring

Opportunity scoring relies on two graphs to rank the Backlog items. First, they use a satisfaction graph, ranking how users like a feature. Then they use an importance graph, measuring how much users value a feature. In examining the two charts teams identify what frustrates their users and what their users want.

Pros of opportunity scoring

• Focuses on ROI (Return on investment)

• Works for many different types of Backlogs

• Helps find gaps between user need and value provided

Cons of opportunity scoring

• Teams need to have an existing product, doesn’t work for new features

• Narrow in scope

3. Kano model

Japanese researcher Noiraki Kano created the Kano model in the 1980s. The Kano model measures user satisfaction to prioritize the Backlog. Using Kano, the team scores Backlog items by several criteria: Must-be, attractive, one-dimensional, indifferent and reverse. Must-be features are those that customers need for the product to function. Customers see one-dimensional features as important and desirable. Attractive features add value and satisfaction. Indifferent features have small or no value to customers. Reverse features have a negative impact on customers.

Pros of Kano

• Ranks features by their value

• Customer-centered

• Gives easy insight into strengths and weaknesses of a feature

Cons of Kano

• Analyzes only customer opinions, not costs or effort

• Kano doesn’t detail resource requirements

4. MoSCoW prioritization

Agile teams use MoSCoW because MoSCoW is simple and easy to use. The acronym stands for Must, should, could and would. MoSCoW allows teams to determine the relative importance of Backlog items. Must means any Backlog item required for a product to function. Should stands for items that have high value to the customer. Could Backlog items are small fixes and features. Would items have the lowest importance and can be added to a future Backlog if the team doesn’t have time.

Pros of MoSCoW

• Easy to use

• Not too technical or mathematical

• Fast 

Cons of MoSCoW

• Zoomed-in view, not an overview

• Not sequenced

5. Value vs Complexity Matrix

This Matrix works well because it maps out Backlog items according to their worth and their difficulty. Value vs Complexity Matrix uses four quadrants to plot these scores. Teams tackle items with high value and low complexity first.

Pros of Value vs Complexity Matrix

• Simple, easy to understand

• Works well to spot easy wins 

• Not math- or analysis-heavy

Cons of Value vs Complexity

• Tends to allow for subjective judgment

• Doesn’t work well for large Backlog lists

Story mapping

Jeff Patton developed Story mapping to add another dimension to Product Backlog prioritization. Story mapping shows more detail than a Product Backlog list. Patton proposes plotting the sequence of the user journey on a horizontal axis. Then we plot the importance on a vertical axis. We group related stories. Agile teams like story mapping for its ease-of-use and transparency. Story mapping gives the team and stakeholders a holistic and rich view of the customer journey.

Pros of story mapping

• Shows complex relationships between different Backlog items

• Flexible

• Gives a full, holistic view of the customer’s journey

Cons of story mapping

• Story maps may become complex

ICE scoring

ICE scoring uses a formula to score Backlog items. ICE stands for Impact, confidence and ease. Impact measures the effect of the change. Confidence measures how certain the team feels about their impact score. Ease shows the teams’ opinion about the difficulty of completion. Teams give each part of ICE, Impact, confidence and ease a score from 1-10.

Pros of ICE scoring

• Good for sorting out the best and most important Backlog items

• Shows which tasks might need the same resources to complete

Cons of ICE scoring

• Possibly subjective

• Scores might differ widely between different team members