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. Let's start with a biggie: value. And while it's a given 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, refactoring is valuable to developers. 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. The second factor 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 take 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: the ongoing cost of delivering features that rely on various artificial intelligence products. These products often include small per-use fees, but those fees can certainly add up at scale. Regardless of the unit in which a team estimates their product backlog items, that cost to develop and support a feature should factor into an item's priority. For example, an item that a team estimates as five 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. A third factor to consider when prioritizing is this: the amount of learning that will occur when the team develops the product backlog item. If you'll learn something important by developing a backlog item, develop that item early so that you have time to act on whatever you've learned. Learn something too late, and 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 occurs when the team develops a feature and receives feedback on it. If users love the feature, do more of it and 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 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? And can the technology be used in other parts of the product or project? 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. 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 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 needed 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. 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. 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 cost. At that point, consider learning, risk, and dependencies. Move the item up an iteration or two if any of those factors is significant. Additionally, there are many ways to prioritize product backlogs, including formal prioritization frameworks such as Kano analysis, RICE scoring, and relative weighting. Even with those formal methods, keep the five factors I've mentioned here in mind, even when they're not explicitly part of those frameworks.