Product backlogs hold all the known features that will eventually find their way into the product. Whether these product backlog items take the form of user stories, job stories, or just a simple sentence or two, it's essential to order the backlog so that teams are always creating the highest priority features. In addition to building the right features, it is important to build them in the right order. Here are the five key things to consider when thinking about how to prioritize the product backlog.
Factor 1: Value
Let’s start with the biggie: value. And while it’s a given to consider how valuable a feature will be, value is a nebulous term.
Value is a measure of the usefulness or impact on a particular audience. Most work an agile development teams will pursue will be valuable to users. But other work may be valuable just to the team itself. Still other work may be to users, stakeholders, and team members.
For example, consider refactoring: improving the structure but not the behavior of code. Because it makes code more maintainable or easier to change, refactoring is of high value to developers.
The cost of refactoring is usually justified, though, because it benefits users, too. If code is more maintainable, users should experience fewer bugs. Similarly, improved code means that users should receive new features in that area of the product a bit more quickly. (For more ways to justify prioritizing refactoring, see "4 Ways to Persuade a Product Owner to Prioritize Refactoring.")
When thinking about the value of a feature, it can be important to think about how the value of a feature degrades over time. A feature might be very valuable today but much less valuable later.
One of the strongest examples I saw of this came while working with a team making software to support fantasy sports leagues. Certain features needed to be there on draft day, when all players selected their teams. If the feature wasn’t available on draft day, players would likely form their league on another platform. The cost of delay in this case was immense.
Factor 2: Cost
The second thing to consider when prioritizing is the cost. The largest cost is usually the product team’s effort to develop a feature. Most teams use story points to estimate the effort of product backlog items. Others estimate that effort in person-days, ideal time, or other similar units.
In some cases there may be additional costs that should be considered. A current common consideration? The ongoing cost of delivering features that rely on various AI products. These products often include small per-use fees but those can certainly add up at scale.
Regardless of the unit in which a team estimates their product backlog items, the cost to develop and support a feature should factor into an item’s priority. For example, an item a team estimates as 5 should be prioritized higher than a feature estimated at 20 if all else is equal. This is true no matter what estimation unit the team is using.
Factor 3: Learning
A second factor to consider when prioritizing is this: How much will a team learn by doing a particular product backlog item? If you’ll learn something by developing a backlog item, you'll likely want to develop that item early so you have time to act on whatever you’ve learned.
If you learn something too late, you won’t have time to benefit from the new knowledge.
Learning can take two forms. It can be about the product or the project.
Learning about the Product
Learning about the product occurs when the team develops a feature, and receives feedback on it.
If users love the feature, prioritize doing more to enhance the feature or creating more things like it. If users don’t love it, consider removing the feature or lowering the priority of related features.
Learning about the Project
Learning about the project refers to knowledge team members gain about how to develop the product or solution. For example, suppose a team intends to build part of a product using a technology that team members have never used before.
When team members develop the first product backlog item using that new technology, they will learn things about it such as:
- Does the technology work as promised?
- Should estimates for using the new tech be revised?
- Can the technology be used in other parts of the product or project?
Don't forget about learning when thinking about agile backlog prioritization. A feature's potential for teaching the team and its stakeholders something about user needs or project realities might be reason enough to make it a top priority.
Factor 4: Risk
The fourth factor to consider when prioritizing is the risk inherent in developing the product backlog item. If something is risky and you need to do it, do it early. You want to know whether that risk is going to materialize.
On the other hand, if a feature is risky and you may not need to develop it, delay working on it until it becomes clear you need to do it.
Factor 5: Dependencies
The final factor you should consider when prioritizing is dependencies between product backlog items. Some items may not be high priority on their own, but they’re necessary for delivering other items. When that’s the case, the enabling but lower-priority item needs to be moved higher on the backlog in order to be done before the item dependent on it.
As an example, consider a summer camp I helped to use Scrum. Among their product backlog items was repainting all the canoes. That was high-priority, because they wanted to show photos of the shiny, newly painted canoes in their marketing.
But painting the canoes was dependent on another backlog item: sand and repair any canoes that need it.
Technically, repairing the canoes didn’t need to be done until a day or two before the summer camp opened, but that item was prioritized higher in the product backlog because the marketing photos of the canoes needed to be taken long before that.
Formal Backlog Prioritization Techniques
Many prioritization frameworks exist to help you consider these factors against one another more granularly including the Kano Model, the RICE scoring model, and relative weighting. Even with those formal methods, when creating a product roadmap, the factors I’ve listed here should be considered even if not explicitly part of these models.
You can, however, achieve a stack ranking of product backlog items by just thinking through these five factors. When doing that, I don’t recommend combining them through some fancy formula. The value of a feature and its cost–our first and second factors–are the most important. So prioritize first based on cost and value, using the other three factors to adjust priorities and resolve conflicts.
For example, suppose a product owner or product manager has prioritized an item such that it won’t be done for another three or four iterations based on its value and risk. At that point, consider learning, risk, and dependencies. Move the item up an iteration or two if any of those factors is significant.
Five Factors for Effective Prioritization
On agile and Scrum teams, product owners are responsible for keeping the product backlog ordered by priority. A straightforward way to approach this, without employing any formal product backlog prioritization techniques, is to keep five factors in mind. Think first about value and cost. Then consider other factors that affect a product backlog item's priority: learning, risk, and dependencies.
When you do this as part of your agile planning efforts, your teams will not only build the right things, they'll build them in the right order.
