Five Factors to Consider when Prioritizing - Mike Cohn
Not only do you need to build the right features, you have to build them in the right order. I want to share five key factors you should consider when prioritizing a product backlog.
Value
Naturally, you need to consider how valuable a feature will be, value is a nebulous term. Most work a team will pursue will be valuable to users. But other work may be valuable just to the team. Still other work may be valuable to both users and team members.
For example, consider refactoring: improving the structure but not the behavior of code. Because this makes code more maintainable or easier to change, developers value refactoring and often request time for it.
Still, the cost of refactoring is usually justified by the way 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.
Learning
When prioritizing a product backlog, consider how much the team will learn by developing each backlog item.
For example, when a team develops a preliminary version of a feature, team members get feedback on whether users like it and how they’re using it. If users love a feature, enhance the feature or consider other things like it.
Other learning is about how to build the product. This might occur when a team uses a new technology for the first time. They might learn if the tech works as promised, or they can develop as quickly with it as they thought, or whether it might be useful elsewhere in the product.
Learning about what to build and how to build it are both valuable.
Cost
The third thing to consider when prioritizing is the cost. The largest cost is usually the team’s effort to develop a feature. Most teams estimate the effort product backlog items in story points but some estimate 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 is 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, and that 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 whether these are story points, person days, person hours, ideal time, or any other unit.
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.
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.
How to Combine These Factors
While all five factors are important, 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.
I recommend continuing to prioritize based on these but then 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.
