Release burnup analysis

Release burnup analysis is the practice of reading a burnup chart to forecast when a release will finish and to see how scope is changing along the way. A burnup chart has two lines: one for total planned scope and one for work completed to date. The gap between them is the work remaining. As the completed line rises towards the scope line, the release gets closer to done.

The analysis matters because it answers two questions at once. The completed line shows whether the team is making progress at a steady rate. The scope line shows whether the plan is growing underneath them. A burndown chart collapses both into a single falling line, which hides scope creep. A burnup keeps them apart, so a flat completed line and a rising scope line tell two very different stories that a burndown would blur into one.

The chart is the artefact, but the forecast is the calculation. Take the work remaining, which is total scope minus completed work, and divide it by the average rate at which the team is completing work. That gives the number of periods left. Add those periods to today and you have a projected release date.

For a worked example, suppose a release has 400 points of scope, the team has completed 240, and the average velocity over the last four sprints is 40 points per sprint. Remaining scope is 160 points, so 160 divided by 40 gives four sprints. If a sprint is two weeks, the projected date is eight weeks out. Recompute it every sprint, because both scope and velocity move.

1. 1

   Total scope

   The full set of planned work in the release, measured in story points or item counts, captured as of today.

2. 2

   Completed work

   Everything accepted as done so far, in the same unit. Only count work that meets the definition of done, not work in progress.

3. 3

   Average velocity

   Work completed per period averaged over a recent window, usually the last three to four sprints, to smooth out one-off spikes.

4. 4

   Remaining scope

   Total scope minus completed work. This is the gap the forecast has to close.

A burnup forecast slipping is a symptom, not a cause. To act on it you have to know whether the date moved because the team slowed down or because the plan grew. A metric tree decomposes the forecast into the drivers that actually move it, so the conversation is about a specific branch rather than a vague sense that the release is late.

When the projected date jumps, you can walk the tree. If velocity is steady but scope rose, the problem is intake, not delivery. If scope is flat but velocity dropped, look at carry-over, blockers, or capacity. KPI Tree connects each branch to the team and the action that influences it, so the person who owns intake sees the scope branch and the person who owns delivery sees the velocity branch. That is the difference between a dashboard that shows a slipping date and a Decision Intelligence model that shows who can pull it back.

There is no single target for a burnup, because the shape depends on release length and how scope is managed. What you benchmark instead is the health of the two lines: how stable velocity is and how much the scope line climbs after the release starts. The ranges below describe what a healthy, watch and at-risk pattern look like over a typical multi-sprint release.

Improving the analysis is less about working faster and more about making the two lines trustworthy. A forecast you can stand behind comes from steady velocity, controlled scope intake, and consistent sizing. The cards below cover the levers that move those branches.

1. 1

   Reading it like a burndown

   Treating a flat completed line as the whole story misses a rising scope line. The gap between the two lines is the point of a burnup.

2. 2

   Freezing the scope line

   Drawing total scope as a fixed horizontal line hides intake. The scope line must move whenever work is added or removed.

3. 3

   Forecasting on a single sprint

   Using one good or bad sprint as the velocity input produces a wildly swinging date. Average over a recent window instead.

4. 4

   Counting work in progress

   Adding nearly-done items to completed work flatters the forecast. Only accepted work belongs on the completed line.