High Value First

Patron saint of supermarkets Dale Winton, with what appears to be a modified high-speed shopping trolley. From the 1960s TV game show “Supermarket Sweep” where teams competed against each other to fill shopping trolleys with the highest-value selection of goods in a fixed time.

... you are a client of a vendor that uses Scrum to develop its product and both are involved in Sprint Planning. You are trying to decide which PBIs to schedule in the next few iterations or Sprints. The Product Ownership role most likely lies on the client side.

The Development Team is working with just one client, so that the relative value of individual Product Backlog Items is clear, using the client as an oracle. The Development Team can readily estimate the PBIs at hand.

✥       ✥       ✥ 

One in the hand is worth two in the bush, and short-term developments should deliver value as early as possible. While an ROI-Ordered Backlog can deliver the highest overall lifetime value, enterprises with quarterly targets don’t want to wait a lifetime to realize such value. It is sometimes more important to realize reasonable value now than to optimize net-present value over the long term. Fixed-scope, fixed-cost projects are an example of when you want to realize value close to the time of client engagement.

In top-down (structured, hierarchically decomposed) development the developers often don’t get good guidance as to the relative business value of the features required. They may spend a lot of effort (time and money) on low value features. Everyone wins if the enterprise achieves high value early.

From the client’s standpoint, some features are essential and some “would be nice to have.” By common economics (the Pareto Principle), 80% of the business value is derived from 20% of the features. To the degree the client is engaged in ordering the backlog the client can get the highest value for their investment. If the client agreement is set up to pay the vendor for time and materials, or if it is a fixed-cost contract, the vendor loses little or nothing as a consequence of such reordering. Particularly in service-intensive businesses, the cost of a Sprint is constant.

It is reasonable to ask the client to express the value of each Product Backlog Item. The Development Team will assign each one a cost (the estimate). This can be difficult to get right in a one-time exercise. What’s worse, the value is likely to change over time as business conditions and strategies change.


Build the high value, most essential, Product Backlog Items first. When the value curve and the cost curve cross, cancel the project. At any point, schedule the highest value remaining PBI in the next available iterations. If the cost of a PBI starts higher than its value you can often split the PBI into its essential and inessential parts. Once these parts are re-estimated you may be in a better position to proceed.

You can streamline the implementation of High Value First by letting the client, in person, direct (or at least propose) changes to the Product Backlog ordering at Sprint Planning. Clients can make on-the-spot adjustments based on the latest net-present value (NPV) data or other available indicator of profitability of individual backlog items. The Product Backlog ordering is driven by client concerns for their own value; the most straightforward way to do this is to locate the Product Owner role on the client side. Rather than following the usual practice where the Product Owner orders PBIs to achieve the highest long-term ROI, the Product Owner prioritizes PBIs according to their incremental contribution to ROI or NPV.

✥       ✥       ✥ 

Having done High Value First you can then follow with Change for Free and Money for Nothing. As an alternative, see the pattern ROI-Ordered Backlog, which sacrifices short-term optimization of the ROI of individual elements to gain the highest ROI (or other value) in the long term.

The value of PBIs will generally decrease as Sprints progress. The cost per PBI will generally increase, as it gets harder to incorporate new PBIs as you go along. Refactoring tries to keep this rising cost curve as flat as possible by keeping the design coherent even as new things are added. At some point, however, the remaining PBIs are probably not worth building. Note that this is one of the major ways that agile processes can save money over planned development: the low value requirements are just dropped. It may also deliver you a product sooner.

In extremely volatile situations the crossing-curves effect may not occur. You might only learn of a high value requirement late in the process so the value curve might take a sharp upward turn. But this ability to quickly retarget the project toward a different goal that delivers value in a different way: you get a more suitable product.

High Value First assumes, of course, that your estimate of value is measurable, and you can optimize overall value only to the degree that it is accurate. This is often difficult to achieve.

Short iterations force you to think in terms of small granularity features. (This is a problem that generally challenges incremental development, but the problem is even more pronounced when using High Value First.) This makes estimation easier, but partitioning harder. If an important, valuable feature is more complex than can be completed in one Sprint, part of it may be delivered in the current Sprint with the rest in the next one (or more) Sprints. If the client sees value only after all parts are done, it becomes impossible to ascribe value to what is delivered in a single iteration, and ordering the backlog by value becomes problematic.

There are often claims that it isn’t at all possible to deliver a specific, valuable PBI piecemeal, Sprint by Sprint. In our experience a PBI can always be broken down so that small pieces can individually can be delivered. Google has 10,000 developers who make more than 5,500 commits daily on their mainline, without using any branching. [1] If you are considering resorting to branching, please reconsider. If you reconsider and still feel branching is in order, reconsider again.

This pattern also assumes that the value is greater than the cost estimate from the Development Team. However, note that no scaffolding was put in place to support these low value features since you have always focused on developing only what is necessary to support an imminent delivery.

There is an additional cost here, since the developers don’t see every Product Backlog Item from the beginning, they cannot make certain optimizations that might lower cost. But these optimizations will waste money if requirements change and make them obsolete; deal with this using Change for Free. Whether the optimizations are worthwhile depends on the delivery horizon of the team: if the changes are more than two or three Sprints hence, they probably will be beyond the Scrum Team’s event horizon.

Complicating this approach is the fact that the first (and every) release needs to create an end-to-end version of the product. Some features will be omitted or be in skeleton form only.

Derived from the original pattern by Joe Bergin. [2] Used with permission. Thanks, Joe!

[1] —. “Google’s Scaled Trunk-Based Development.” PaulHammant.com, https://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/ (accessed 2 November 2017).

[2] Joe Bergin. “High Value First.” In Agile Software: Patterns of Practice. New York: Software Tools, 2013, pp. 35-6.

Image from http://www.londonlovesbusiness.com/business-news/retail/supermarket-sweep-lidl-and-aldi-riding-high-doubling-market-share-in-just-three-years/11376.article.