How to prioritize the Product Backlog
Prioritizing the Product Backlog is an important part of the development process. Determining what to develop first and prioritizing helps you plan your work effectively.
This article introduces the importance of prioritizing the Product Backlog, techniques for creating priorities, and how to maintain them.
What you can learn from this article
- On the Importance of Prioritizing the Product Backlog
- 5 Factors to Consider in Product Backlog Priorities
- Introducing a Product Backlog Prioritization Methodology
- Product Backlog Prioritization | Differences between MoSCoW and Kano Model
- Product Backlog Prioritization Anti-Patterns/Failures
- How to review and maintain product backlog priorities
- Product Backlog Prioritization FAQ | Tell me, Joe!
Importance of Prioritizing the Product Backlog
A useful product is one that efficiently solves a user’s problem, not one that is packed with features.
Prioritizing the Product Backlog is necessary to develop critical features and avoid overload (and high costs).
Creating only the necessary and essential functionality is a great way for companies to save money and time.
A prioritized backlog also facilitates planning releases and next iterations .
5 Factors to Consider in Product Backlog Priorities
① Business value
What is the value created by implementing the feature?
(Increase profits, reduce costs, improve quality, improve stakeholder satisfaction, etc.)
② Size (labor/cost)
What is the effort size to implement the feature? Need to spend more resources?
(user story complexity, risk, uncertainty, level of effort required to complete)
③ Technical dependencies
Items in the Product Backlog may have dependencies. Dependencies should consider development order.
④ Reduction of risk
Will implementing the feature reduce uncertainty or reduce risk in future work?
⑤ Ability development
Will it lead to new team development?
Balancing these five factors is not easy. Prioritizing the backlog
is therefore one of the most difficult decisions for Product Owners to make .
The product owner is responsible for prioritizing the backlog, but team members support this decision-making.
To help you use the best prioritization method for your team, here are the most commonly used backlog prioritization methods:
Introducing a Product Backlog Prioritization Methodology
Product Backlog items can be new feature requests, user stories, bugs, change requirements, technical debt, improvement items from retrospectives, etc.
The difficulty is how to distinguish between required and unnecessary features.
This is where agile and prioritization techniques come into play.
Here are some product backlog prioritization techniques.
There are several Product Backlog prioritization techniques.
We will explain each method in detail.
Prioritizing value vs effort (difficulty)
This matrix evaluates based on relative ratings of value and features’ effort (difficulty) taken to implement .
Value vs Effort (Difficulty) uses the 4 quadrants to place backlog items. Teams work on high value, low effort (difficulty) items first.
- simple, easy to understand
- No emphasis on mathematics or analysis
- Tend to make subjective judgments
- Does not work well with large backlog items and many dependencies
Kano model prioritization
The vertical axis reflects customer or end-user satisfaction. The right axis represents the customer requirements that the product satisfies. The left axis represents unmet customer needs. These fall into his five categories:
Basic functions : must-have functions
Performance features (satisfactory) : Features in this category are more satisfying with better performance and dissatisfied with poorer performance. (For example, the longer your smartphone battery lasts, the better.)
Attractive features : Features that surprise and delight end users. It’s not a must-have feature, but having it increases satisfaction.
Indifference : The presence or absence of this feature has no impact on customer value.
Converse : Dissatisfaction arises if this category of functionality exists. These features can frustrate your customers, so you should avoid building them (further) or leave them out of your product entirely.
- Rank features by their value
- Easily understand the strengths and weaknesses of features
- Not considering the time and resources required to build the product
- Researching the target market can often be time consuming
MoSCoW stands for the acronym “Must” “should” “could” “would” .
MoSCoW allows teams to determine the relative importance of backlog items. A must is a backlog item that is necessary for the product to function. It should represent an item of high value to the customer.
- Not too technical or mathematical
- Easy to understand and fast to create
- The big picture of the product is not considered
- There can be an imbalance between what is needed and what is desired
RICE stands for “Reach,” “Impact,” “Confidence,” and “Effort.”
• Reach: How many users are affected over time?
The team quantifies the number of customers using the feature benefit from the backlog item.
Whenever possible, this number should be derived from actual data rather than guesswork.
Example: Users actually reached = ◯◯◯ people
・Impact : How much will the chosen backlog impact each user?
Ask the team to make an educated guess about how much the backlog’s features might impact users.
Ask the team to make an educated guess about how much the backlog’s features might impact users.
Example: High impact = 3 / Medium impact = 2 / Low impact = 1
・Confidence : How confident are you in your reach, impact, and effort estimates?
Measures your team’s confidence in your estimates.
Example: High Confidence = 100% / Medium Confidence = 80% / Low Confidence = 50%
・Effort: How long will it take to implement this?
Measures the amount of work the team will need to expend to complete the backlog item.
Example: low effort = 2 / medium effort = 3 / high effort = 5
- Based on real data utilization and KPIs, more accurate
- Time consuming
- Data may not match
- Teams may have to guess many items
Prioritizing Opportunity Scoring
Opportunity scoring (also called Opportunity scoring or gap analysis) uses two axes to rank backlog items.
First, use satisfaction (vertical axis) to rank how satisfied users are with a feature. Then use Importance (horizontal axis) to measure how important users value the feature.
Features that users deem important, but underdeveloped, are an opportunity.
Opportunity Score = Importance + max(Importance – Satisfaction, 0)
Calculation example ①: Importance 1 Satisfaction 10
Opportunity score = 1 + max(1-10, 0) = 1
Calculation example ②: Importance 10 Satisfaction 1
Opportunity score = 10 + max(10-1, 0) = 19
- Helps find gaps between user needs and feature value provided
- Teams must have existing products, no new features
- May underestimate or overestimate the importance of features
Prioritizing user story mapping
By organizing user behavior in chronological order and mapping the functions and requirements necessary to realize it, you will be able to visually grasp the purpose and priority of the value realized by the product.
While sorting user stories, you can define a minimum set of features (MVP: Minimum Viable Product) that are valuable to users, and help you identify a list of requirements for the first release.
- It will be an epic with a rough structure to be developed such as backbone “member registration” “search” “select” “payment” and “close”.
- The walking skeleton is a user story of the smallest unit, such as “new user registration” and “login function”, by making “member registration” more detailed.
- Can be released quickly as an MVP
- Can be released quickly as an MVP
- Focuses only on core features
Prioritizing the Eisenhower Matrix
The Eisenhower Matrix is a technique for organizing and prioritizing tasks according to their urgency and importance.
Eisenhower built on this philosophy, saying, “What is important is seldom urgent, and what is urgent is seldom important.”
- High Priority: Urgent and Important
- Medium priority: important but not urgent
- Urgent but not important
The included features are urgent but do not have a significant business impact on the product, so the team should decide if they are really needed “now”.
- Low priority: neither urgent nor important
- Simple and easy to understand
- Easy to judge interrupt work etc.
- Fewer items to consider
- Technical elements (labor efforts and cost) are not considered
Product Backlog Prioritization | Differences between MoSCoW and Kano Model
I am often asked about the difference between MoSCoW and the Kano model.
Let’s sort out the differences.
MoSCoW was developed in 1994 by Dai Clegg, an Oracle consultant. MoSCoW was popularized in DSDM (Dynamic Systems Development Methodology) in the early 2000s. As Agile grows in popularity, it is widely used as a prioritization method .
The Kano model was proposed by Japanese professor Noriaki Kano in the 1980s.
Known worldwide as the Kano Model, it has had a major impact on the fields of marketing and quality control.
In general, customer satisfaction is assumed to change according to the degree of satisfaction of quality, but the Kano model states that the effect on customer satisfaction varies depending on which quality element the quality corresponds to.
So don’t just identify must-have features, focus on what your customers really value . This is also useful when assessing attractiveness features.
Product Backlog Prioritization Anti-Patterns/Failures
It’s also important to be aware of product backlog prioritization anti-patterns and failure cases.
- Too many items in the product backlog
- Lack of product vision
- Trying to provide more features than they are worth
Prioritizing dozens of items is difficult.
When will the bottommost backlog item be completed? Customers become dissatisfied as lead times lengthen.
Organize the items you already have using story maps. Revisit your product vision with your team and remove what is not currently needed.
If the item is not important in the next few sprints or months, it should not be added to the Product Backlog.
And most importantly, Product Owners need to learn to say “NO”.
How to review and maintain product backlog priorities
Review and maintenance of priorities
The Product Backlog is not finished once completed. The business environment is constantly changing, including stakeholders involved in products, customers, and market needs.
To keep the backlog current and use it effectively, it must be continuously managed and improved.
As the product grows, it is often the case that the Product Backlog increases. This means that you may have too many backlog items.
When items are not organized according to business needs, they become difficult to manage and lack transparency.
Now that you have understood the importance of maintenance, I will continue to briefly explain maintenance methods.
Review and maintenance of product backlog items (PBI)
To keep your product backlog manageable, consider the following:
- Check your backlog regularly
- Delete user stories you no longer need
- Create new user stories based on newly discovered needs
- Reconsidering priorities
- Re-estimate work size
- Review of definition of completed and definition of ready
The Product Owner should work to maximize outcomes by making the backlog manageable .
Product Backlog Prioritization FAQ | Tell me, Joe!
- Who is responsible for prioritizing the Product Backlog?
The Product Backlog is the responsibility of the Product Owner. Therefore, it is the product owner’s responsibility to prioritize. The Product Owner thinks in terms of maximizing the value of the product. The team should support the Product Owner’s decisions, including from a technical perspective.
- What criteria should I use to choose a Product Backlog prioritization method?
Choosing which prioritization framework to use can be difficult. There are many prioritization methods, and finding the right one for your team and product also depends on your needs and vision. Give it a try, get feedback, iterate, and see what works for your team and product!
- Can I change the priority of the product backlog if it fails?
It’s not just failures, it’s possible that priorities change. Especially in the early stages of the product, the uncertainty is high and it is difficult to decide everything. Correct your trajectory in the next sprint and you’ll be fine. That’s why we recommend reviewing the Product Backlog daily. You can adapt and improve your daily awareness.
- How should the Scrum Master relate to product backlog priorities?
It is important that the Product Backlog priorities are agreed and understood by the team. The Scrum Master works to get all product owners and developers in agreement. The Scrum Master contributes to the success of the project by helping both the Product Owner and Developers.
A business perspective and a technical perspective are essential for backlog prioritization.
Therefore, creating and prioritizing the Product Backlog should be done by the whole team. This also helps bring autonomy and a collaborative working environment within the group.
Summary of product backlog priorities
Prioritization is an essential skill for every product owner and team. I’ve introduced a few prioritization techniques, but there are many others.
Which method to choose depends on the product and team, and it is difficult and there is no correct answer.
We hope this article is a good starting point for you to experiment with and explore different prioritization techniques.