ROI-Ordered Backlog

... you have a backlog of Product Backlog Items and need criteria to order them on the Product Backlog.

✥       ✥       ✥ 

It is the responsibility of the Product Owner to optimize ROI (return on investment), usually in the long term. The Product Owner strives to this end by ordering the items in the Product Backlog. The backlog must be a single, ordered list of PBIs (Product Backlog Items) to bring focus to the Development Team, and the entire enterprise, on the deliverables.

You could order PBIs by the priorities of your dominant customer. However, that might lock out other customers, and in any case tends to focus on revenues rather than costs. Since cost is also a key consideration in ROI, focusing on customers alone isn’t enough.

You could order them by the priorities of the Product Owner in isolation. But the question arises: What criteria should the Product Owner use to set the priorities of the Product Backlog Items?

Most Product Owners annotate each PBI with a tentative ROI or other business value. One might be tempted to order the Product Backlog with the highest ROI items first. However, the value of a PBI is in part a function of what other PBIs have preceded it in being delivered, in part on the timing of delivery to the market, and in general on the item’s position in the backlog. And because we are agile and the business is dynamic, PBI positions on the backlog may change frequently even during a Sprint. So while an ROI annotation on a PBI may be a useful temporary convenience, it doesn’t prescribe an ordering that will always ensure the best long-term ROI.

Properly ordering the Product Backlog Items to line up development dependencies foreseen by the Development Team can avoid rework and facilitate a smooth flow of products to market. So you could order PBIs solely according to the team’s insight on dependencies, but that misses out on major revenue-generating opportunities that may arise for PBIs whose ordering is less constrained.


The Product Owner orders PBIs in a way that generates the largest long-term ROI. The Product Owner must account for both revenue and cost. If the Product Owner re-orders PBIs, then he or she must account for the resulting ROI changes to the affected Product Increments. The Product Owner is empowered to make decisions on behalf of all the stakeholders, but would be wise to balance the supplications and insights of all stakeholders in balancing the ROI equation.

While the common Scrum measure is “ROI,” a Product Owner may certainly choose to optimize Return on Equity (ROE), Net Present Value (NPV), or any other measure or indicator of value. In general, Scrum supports the enterprise in optimizing any value, including non-economic values such as corporate reputation, staff esprit de corps, minimal turnover, number of clients served, etc. Most Product Owners will want to optimize a combination of several such values.

✥       ✥       ✥ 

The Value Stream will be set up to produce Regular Product Increments with the best possibility of generating high long-term value.

This evaluation rarely can reduce to a formula. Such ordering is always imperfect and benefits from good judgment, insight, and experience.

The notion of priority for PBIs is flawed. The term priority is an attribute of an individual element of a collection that is to be ordered. However, we are focused on ROI rather than a token quantity, such as a priority, in ordering the Product Backlog. There often can be no linear correspondence between priority and ROI. You can’t sit back and assign context-free priorities to PBIs and then sort the Product Backlog, because a PBI’s ROI is often a function of its position in the backlog. Some market offerings make sense only if they build on previous offerings; some market offerings are sensitive to market timing. Re-ordering items can change the ROI contribution of each one; in fact, Jeff Sutherland notes that you can as much as double your long-term ROI just by re-ordering the PBIs.

One point of the solution is worth reiterating: ROI needn’t be just about money. In general, it is about value. Most value systems are rooted in the economic theory of value: the ability to exchange one artifact or token of value for another of equal value. However, an enterprise may also value employee retention, good customer relations, a good public image, or many other desiderata that fall outside the economic theory of value. Most items of value can be viewed as a return on some kind of investment. See, for example, Team Sprint.

To serve process improvement it is best that ROI be measurable.

As an alternative approach, see High Value First, which can support the well-known patterns Change for Free and Money for Nothing. If you order the Product Backlog by long-term ROI, you can’t easily use Change for Free or Money for Nothing.

Picture from: