The value stream

Release plan and roadmap

Stakeholders want to know what will be delivered and when. Scrum cannot guarantee it, but it lets you forecast it honestly from what the team has actually delivered so far. Ten patterns from A Scrum Book deal with this forecast, with the calendar constraints that bear on it and with contracts that leave room for change.

"I need a date"

At an adult education provider, a team of five trainers produces the modules for the fall catalog in two-week Sprints. The director questions the Product Owner.

"Will the catalog be complete on September 1?"

"I can show you what we have finished over the last five Sprints and what that points to. I can't guarantee you a date for the whole thing."

"I need a date for the printer."

"Then I'll give you two things: the list of modules that will certainly be ready on September 1, and a range for the others."

This answer applies the first two patterns in this article.

Release Plan: reading releases off the Product Backlog

The Release Plan pattern assumes an estimated Product Backlog and a known velocity. The Product Owner must be able to say when the next version will come out and what it will contain. The main constraint is sometimes the date, sometimes the content. Imposing both at once creates an overconstrained problem, whose risk the Product Owner must make visible. Without agreement on the content, requesters believe they can add to it until the last day, and the release slips. A plan written by the Product Owner alone ignores what the Developers know, and they will not feel committed to it.

The solution is to build, with the Developers, a Product Backlog that expresses the sequence of Increments leading to the vision, and then to read it as a plan. You start at the top of the list and add up the estimates until you reach one Sprint's velocity. Those items form the next release, and you carry on down the list. The calculation includes all the work needed to reach the Done state, with no separate finishing phase. The authors set two safeguards. Beyond three Sprints, the forecast is more guesswork than projection. And no date in the plan should be read as a firm commitment.

Release Range: announcing a range

The Release Range pattern responds to a stubborn habit: a single date is taken as a promise. Yet an estimate is only the best guess of the moment. A team member gets sick, a problem resists, velocity changes. Asking the team for an optimistic and a pessimistic figure for each item takes time and rests on impressions.

The solution draws the range from history. You take the lowest and the highest velocity of the last three to five Sprints. You divide the total of the estimates to be delivered by each of the two, which gives a pessimistic and an optimistic completion date. The same calculation, carried out for a fixed date, gives a range of content. The authors compare this practice to the cherry blossom forecasts in Japan, announced every year as ranges of dates. They advise against communicating only the pessimistic bound, which would be received as a commitment.

Product Roadmap and Set-Based Design: keeping options open

The Product Roadmap pattern starts from the fact that several paths lead to the goal and that nobody knows in advance which is best. Clinging to a single plan leads to exhaustion when reality departs from it. A good Product Owner keeps alternatives in reserve, but the Product Backlog has only one dimension and shows only one order of delivery. The solution is a roadmap drawn as a graph, with decision points and branches, annotated with known costs and values. The Product Backlog becomes the day's best hypothesis about the path to follow on this map, and the release plan is derived from it. The authors want a simple roadmap, limited to strategic choices, which shows alternatives and dependencies rather than a release schedule. In this it differs from the feature calendar that many companies call a roadmap.

The Set-Based Design pattern deals with the same uncertainty at the level of solutions. Choosing one option early and developing it fully exposes you to starting over when new information contradicts it. Iterating improves an idea, but the authors, drawing on an article by Jakob Nielsen (1993), consider that this is not enough to give rise to a radically new one. The solution, borrowed from Toyota, is to develop several options in parallel while fixing only the critical constraints, to compare them midway and to eliminate some. The remaining options gain precision at each stage, from sketch to prototype. The training team hesitating between an online quiz, a case study and a filmed role-play can sketch all three in a day each, try them with two trainees, then develop only one. The authors point out the human cost of a discarded option and the risk, within a Sprint, of producing no Increment.

Fixed-Date PBI and Vacation PBI: what the calendar imposes

Some events do not depend on the team, such as a supplier's delivery or a law coming into force. The Fixed-Date PBI pattern asks the Product Owner to place each item blocked by such a dependency at the position in the Product Backlog that corresponds to the date when it will become feasible, to note that date and to place below it the items that depend on it. The position is checked often, since the rest of the list moves.

The Vacation PBI pattern applies the same idea to planned absences. The usual practice is to lower the velocity for the Sprint concerned, then to restore it. The authors object that velocity is an observed measure and that a manual correction turns it into a calculation for which nobody feels responsible. They propose entering the absence as a Product Backlog item, estimated by the Developers, because a team's output is not proportional to its headcount. If the training team, whose average velocity is 20 points, estimates the absence of two trainers in August at 6 points, 14 points remain for that Sprint's modules, and everyone can see why. The book acknowledges that putting a public figure on one person's absence is delicate, and that the pattern does not apply to unforeseen illness.

Release Staging Layers: delivering in circles

Feedback from real users is the raw material of an agile team, but delivering every Sprint to the whole market is expensive and risky. Customers do not all have the same tolerance: some want new things early, even if imperfect, while others demand a proven product. The Release Staging Layers pattern recommends defining successive audiences, from volunteer testers to the whole market, and delivering every Sprint to at least one of them. The book cites the release channels of the Chrome browser. A training provider can do the same: a pilot group receives each new module, then two partner employers, then the catalog. The authors specify that each circle receives a Done product, and that the existence of a first circle must not serve as an excuse for lower quality.

Change for Free and Money for Nothing: contracts that allow for change

These two patterns concern a team working for a client under a fixed-price contract. According to the book, Jeff Sutherland formulated them during a training course given in the Netherlands in 2006.

Change for Free starts from the observation that needs emerge after signature and that charging for each change destroys trust. The solution is to commit by contract to the 80% of items that matter most to the client, and to allow the client to swap a new request for an existing item of equal or lesser value to them, provided the cost of building it is no higher. The pattern assumes a stable team, experienced in the domain and able to estimate everything from the start.

Money for Nothing makes use of the order of the Product Backlog. Since the items of greatest value are delivered first, each delivery brings less than the one before, and there comes a point where continuing costs more than it brings in. The solution is to stop at that point. The contract gives the client the right to stop at the end of a Sprint, in return for a cancellation fee.

Value Stream Fork: splitting a product that has grown too broad

A successful product expands and ends up serving markets whose needs and rhythms diverge. A single Product Backlog then has to interleave several schedules, the team loses focus and adding teams increases the cost of coordination. The Value Stream Fork pattern proposes, when at least two streams have distinct cadences or contexts, splitting the product into several products, each with its own Product Backlog and Product Owner. The alternative, which keeps a single backlog, is presented in the article on scaling up.

What the 2020 Scrum Guide says

• The Guide mentions neither release plan nor roadmap nor velocity. Its long horizon is the Product Goal, progress toward which is inspected at least once a month.
• It accepts forecasting practices, while recalling that only what has already happened may be used for decision-making. This principle supports a range calculated from history.
• The 2017 edition asked the Product Owner to track the remaining work at least at every Sprint Review. The 2020 edition removed that passage.
• The patterns on contracts, vacations and release staging layers belong to the book alone.

Limits and pitfalls

A range does not survive being passed along well. From one report to the next, the optimistic bound becomes "the date". The book itself slides into the language of probability, saying there is "an 80 percent chance that the release will be ready" on a given day: yet the lowest velocity of five Sprints is not a probability, and the authors admit elsewhere that too many factors vary to claim statistical certainty.

The calculation assumes a stable team, consistent estimates and a Product Backlog that hardly changes. None of these conditions holds for long, hence the three-Sprint horizon. A velocity scrutinized by management also tends to inflate, as the article on estimation and velocity explains.

The contract patterns rest on an example told by Sutherland in his 2014 book: a client is said to have paid 3.2 million dollars for a product priced at 10 million, delivered seventeen months early, while the supplier's margin went from 15% to 60%. No independent source is cited in support. These clauses also require a degree of trust and an ability to estimate that few business relationships combine.

More generally, these ten patterns are practices drawn from experience, and their authors rate several of them as one solution among others. The corpus's critical article sets out what this implies.