...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 Product Backlog Items (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 the relative value of individual Product Backlog Items is clear, using the client as an oracle. The Development Team can readily estimate the PBI 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 percent of the business value comes from 20 percent of the features. To the degree clients are engaged in ordering the backlog, they 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 as a one-time exercise. What’s worse, the value is likely to change over time as business conditions and strategies change, and value changes with the ongoing delivery of Product Backlog Items.

Therefore:

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 the Scrum Team and the client re-estimate these parts, 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. A client can order the Product Backlog to optimize 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 value (see Value and 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. In software, refactoring tries to keep this rising cost curve as flat as possible by keeping the design coherent, even as the product evolves. 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 development effort just drops the low value requirements. You may also deliver the 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 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. Errors in the estimates can quickly come to be larger than the differences in PBI value.

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. It can cause the team to focus too much on wasteful over-specifying and over-planning. If an important, valuable feature is more complex than the team can complete in one Sprint, the team may deliver part of it in the current Sprint with the rest in the next one (or more) Sprints. If the client sees value only after the team has delivered all the parts, it becomes impossible to ascribe value to the Product Increment of any single Sprint, and it becomes problematic to order the backlog by value.

There are often claims that it isn’t at all possible to deliver a specific, valuable PBI piecemeal, Sprint by Sprint. In our experience, the Scrum Team can always break down a PBI so that the team can individually deliver small pieces. 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 the team doesn’t have to develop any extra scaffolding to support these low-value features since the team always focuses 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 the optimizations 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 away, they are probably beyond the Scrum Team’s delivery horizon.

Complicating this approach is the fact that the first (and every) release needs to create an end-to-end version of the product. It may be that the team delivers some features in skeleton form only, or that it temporarily disables some features for a single release.

We derived this pattern from the original pattern by Joe Bergin ([2], “High Value First,” pp. 35–6). Used with permission. Thanks, Joe!

[1] John Thomas and Ashish Kumar. “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–36.

Picture credits: JTV, Jackson, Michigan, USA, https://jtv.tv/supermarket-sweep/