The value stream

From Vision to Product Backlog

A team rarely lacks ideas. More often it has too many, championed by different people, and it cannot carry them all out at once. Scrum's patterns describe the path that leads from a common intention, the Vision, to a single ordered list, the Product Backlog. This article follows that path and explains the criteria used to decide the order.

Too many ideas for one team

What this team lacks is a shared direction and a way of deciding what comes first. In A Scrum Book (2019), Jeff Sutherland, James Coplien and their co-authors describe Scrum's answer through a chain of patterns. A pattern is a proven solution to a recurring problem, presented with its context and the forces that pull against it.

The Vision, a direction the team makes its own

The Vision pattern (the authors also call it Product Vision) starts from a tension. People with varied backgrounds bring ideas that no single one of them would have had, but without a common goal they pull in different directions. A goal that is too vague lets the team scatter over paths of little interest. A goal that is too narrow takes away its creativity and turns its members into mere executors. The future is also too uncertain to commit to a detailed plan long in advance.

The proposed solution is as follows. The person who champions the project with the most conviction takes the role of Product Owner, the person accountable for the value of the product. Around them, the stakeholders (everyone concerned by the product) and the future teammates formulate and then refine a Vision together: a description of a desired future and of how the product contributes to it. The authors insist on this joint work, because a team only takes a goal to heart if it has helped to formulate it.

The pattern distinguishes two levels. The Vision gives a broad direction, and the Product Vision makes it more specific. Drawing on Roman Pichler (Agile Product Management with Scrum, 2010), the authors list what a Product Vision usually contains: the product's main features, its users, the needs it meets and the benefit the organization gains from it. As an example they cite Bill Gates and Paul Allen's vision of "a computer on every desk and in every home." A Vision is corrected as the team learns.

At the library, after two meetings with the deputy mayor, the staff and a few users, the director settles on this sentence: "Every resident of the neighborhood has a reason to come to the library at least once a month." The sentence does not say what to do, but it already makes it possible to compare the ideas with one another.

The Value Stream: the path from idea to user

A good idea and competent people are not enough. The path by which the idea becomes a service delivered matters as much as the idea itself. This is the problem addressed by the Value Stream pattern. The authors define value there as what is worth something to the people you want to serve.

The solution is for the Product Owner to build a coherent set of artifacts, events and people, at the center of which a process regularly delivers Increments to the stakeholders, that is, usable and enriched versions of the product. The pattern sets an organizational rule: a single Scrum Team (the Product Owner, the Scrum Master and the Developers) carries out all the development of a value stream, with no major handoff to other teams. Every handoff delays feedback, and that delay is paid for in rework. The stream also flows the other way, since users' comments and the defects they find travel back to the team.

The notion comes from Lean: the authors refer to the Toyota Production System and to value stream mapping, which the Lean corpus presents in Value stream mapping (in French). At the library, the stream starts with an idea for a service and ends when a resident benefits from it. If cataloging depends on a town hall department that takes three weeks to reply, that handoff will slow everything else down.

The Product Backlog, a single ordered list

The Product Backlog pattern answers the problem of the opening scene. A team cannot do everything at the same time and must keep its focus. Stakeholders need to see where the product is heading. The order of delivery has to take account of dependencies between pieces of work and of the calendar. If everyone keeps their own list, nobody can see that order.

The solution is to keep, for each product, a single list whose items are arranged in the order in which they are expected to be delivered. The Product Owner has the last word on its content and its order, but builds it with the Developers, the people who build the product. The list is visible to everyone, and the Developers take work from no other source.

The authors add two clarifications. The Product Backlog is not a requirements specification: it records the team's planning decisions, and the details are discussed face to face. In addition, forecasts drawn from it only make sense for two to five Sprints (the Sprint is the fixed-length work period, one month at most, that sets Scrum's rhythm).

The Product Backlog Item

Each line of the list is a Product Backlog Item (PBI). The pattern defines it as the description of something the Developers can build and deliver, and which brings value to a stakeholder once it is done. A good PBI has an easy-to-remember name, an estimate provided by the Developers and a note on the expected value. It says what, when and for whom, and leaves the how to the Developers.

The authors hold to one distinction: a PBI describes a deliverable, whereas a user story (a short narrative of the form "as a reader, I want… so that…") describes a person's need and motivation. A single deliverable can answer several stories. They also advise against putting the team's internal tasks into it, since those belong in the Sprint's work plan. At the library, "buy twelve transport crates" is a task. "Residents of the Les Tilleuls nursing home receive five books chosen with them every month" is a PBI.

Four patterns for deciding the order

Value and ROI

Scrum long referred to value by the acronym ROI (return on investment). The note Value and ROI broadens its meaning. The authors point out that the Scrum Guide does not use the term ROI and speaks only of value. For a public service, value may be measured by citizens' satisfaction. Following the engineer Arthur D. Hall (A Methodology for Systems Engineering, 1962), they distinguish economic value, psychological value (people's satisfaction) and a value they call casuistic, that of doing what is right.

ROI-Ordered Backlog

The ROI-Ordered Backlog pattern looks for the ordering criterion. Following the wishes of the most important customer pushes the others aside and neglects costs. Following only technical dependencies means missing opportunities. Sorting items by the value noted on each one seems obvious, but the value of an item depends on what has been delivered before it and on when it arrives.

The solution is for the Product Owner, after listening to the stakeholders, to order the list so as to obtain the greatest long-term value, counting both revenues and costs. The authors make clear that this choice rarely comes down to a formula and that it calls for judgment. They draw a point of vocabulary from it: "priority" is an attribute attached to an isolated item, whereas value arises from the position of each item within the whole. The Scrum Guide made the same choice in 2011, replacing "prioritized" with "ordered". At the library, the homework space is worth more if it opens in September than in May, and home delivery depends on the online catalog having been rebuilt.

High Value First

The High Value First pattern, adapted from Joe Bergin (Agile Software: Patterns of Practice, 2013), offers another route for a specific context: a single customer commissions a development from a supplier, and the Product Owner role sits on the customer's side. There, reasonable value obtained early counts for more than maximum value obtained late. The solution is to build the highest-value items first, to take the best remaining item at each Sprint, and to stop the project when the cost of a Sprint exceeds the value it brings.

ROI-Ordered Backlog and High Value First are presented as two options: the first accepts a small loss in the short term to gain more over time, while the second does the opposite and opens the way to the forms of contract described in the article on the release plan.

Greatest Value

The Greatest Value pattern deals with a common failing: a team that calculates value as the sum of its parts improves each part at the expense of the whole. The solution it asks for is to seek the greatest overall value, at the widest scale over which the organization has influence, and to conduct local work with that view in mind. The authors cite two products from a European telecommunications software company that shared a database: a change that was costly for one of them served the whole, and the two Product Owners decided together to make it.

What the 2020 Scrum Guide says

The book dates from 2019 and is based on the 2017 edition of the Scrum Guide. The 2020 edition differs on a few points.

• The Guide does not mention a Vision. In 2020 it introduced the Product Goal: a future state of the product that serves as a target for the Scrum Team, is recorded in the Product Backlog, and must be fulfilled or abandoned before the team takes on another.
• The Guide describes the Product Backlog as an "emergent, ordered list of what is needed to improve the product" and as the single source of work for the Scrum Team. On this point it agrees with the pattern.
• The Guide uses neither ROI nor Value Stream, and it prescribes no format for Product Backlog items.
• The book writes "Development Team"; since 2020, the Guide says "Developers".

Limits and pitfalls

A Vision written by management alone and pinned up in a corridor does not fulfill the function described by the pattern, since nobody has made it their own.

The Product Backlog degrades in two common ways. It becomes a dump of several hundred lines that nobody reads anymore, or it coexists with parallel lists, such as the "urgent jobs" a manager passes straight to the Developers. The order itself is distorted when it reflects the loudest voice, or when everything is ranked "priority 1".

Value figures call for caution. The authors acknowledge that the estimation error can exceed the difference in value between two items. They also report that, according to Jeff Sutherland, reordering a backlog can double the value obtained: this is a practitioner's claim, which the book supports with no measurement. Finally, High Value First assumes that each piece delivered has value of its own, which is not the case when a service is only useful once complete. The article Criticism and the state of the evidence returns to the status of these recommendations.