12Tracking the release

A release forecast stays honest only if progress is tracked against it, sprint after sprint, in a form stakeholders can read. Tracking is also where most stakeholders actually see the plan. Several kinds of chart exist, and they differ in one important respect: whether they show progress and scope change separately.

To compare them, the charts below use the same illustrative data: the Blood tests team's part of release 2 from section 8, 240 points at the start. During sprint 2, refinement of "handle positive results" reveals 30 more points of work. During sprint 4, a customer asks for an additional test, 15 points. During sprint 5, 20 points of optional work are deferred to a later release, using the feature buffer. Six sprints have been completed.

The release burn-down

The simplest chart plots the points remaining at the start of each sprint. Its slope shows net progress. Its weakness is that it mixes two things: a flat stretch can mean the team did little, or that it did a lot while scope was being added. The chart cannot tell which, and those two situations call for very different conversations.

The release burn-down bar chart

Mike Cohn's answer is to draw each sprint as a bar. Completed work lowers the top of the bar. Added scope extends the bottom below zero; removed scope raises it. Progress and scope change are now shown separately, and trend lines through the tops and through the bottoms give a forecast: the release completes roughly where they meet.

[embedded content: illustrative data · Blood tests team, release 2, six sprints]

The tops fall steadily with completed work. The bottoms show the scope that was discovered and added, and rise again when work is deferred.

The release burn-up with a forecast range

The burn-up shows the same information differently: completed work rises towards a separate line for total scope, and every scope change appears as a step in that line. Most stakeholders read it more easily. Extending the completed line at the best and worst recent velocities gives a forecast range, drawn as a fan. It should narrow sprint after sprint: it is the cone of uncertainty from section 4, made visible on a real release.

[embedded content: illustrative data · same release as the chart above]

Each step in the scope line is a decision or a discovery that stakeholders should hear about. The fan shows the forecast as a range rather than a date.

Two charts, two assumptions

The two charts do not give the same answer, and the difference is instructive. The bar chart's trend lines extend the past, including the past rate of scope growth, so they assume scope will keep growing. The burn-up's fan assumes scope stops changing. The gap between the two forecasts is the price of continued scope growth, and it is exactly the conversation to have with stakeholders: if scope keeps growing at this rate, the release slips by a sprint or more.

Several teams: the parking-lot chart

With several teams, keep one chart for the release and one per team: the release completes no earlier than its slowest team, and the per-team charts show where help is needed. For executives, Cohn's parking-lot chart summarises the release in one view: one box per theme or area, with its percentage complete and a status colour. In the BECS example, four boxes, Donation, Manufacturing, Blood tests and Inventory, tell a steering committee in a few seconds where release 2 stands and where it is at risk.

Rules that keep tracking honest

  • Count only what is done. Only stories that meet the Definition of Done count. No partial credit for a story that is "80% done".
  • Separate added from discovered scope. They have different causes and call for different conversations.
  • Don't re-estimate completed work. Re-estimation applies only to what remains.
  • Track scope, not hours. Hours spent say nothing about what users will receive.
  • Use charts for conversation, not surveillance. Once teams are judged by the shape of a line, the line starts to lie.

Teams working in continuous flow can track the same release with a cumulative flow diagram and probabilistic forecasting from throughput, discussed in the next section. The principle does not change: progress and scope are shown separately, and the forecast is a range.

Section takeaways

  • Choose charts that show progress and scope change separately: the burn-down bar chart or the burn-up.
  • Show the forecast as a range. It should narrow sprint after sprint; when it doesn't, find out why.
  • Count only work that is done, make every scope change visible, and use the charts to start conversations, not to judge teams.