It’s week five of a twelve-week release. Someone pulls up the burn up chart in the planning sync, and the line everyone watches, completed work, is climbing nicely. Then somebody points at the other line. The total-scope line has stepped up three times since the PI confidence vote. Nobody is alarmed, exactly. The chart is doing its job. But the question in the room goes unanswered: does the committed date still hold?
The burn up chart can’t answer that. It was never built to.
What a burn up chart does well
A burn up chart plots two lines over time: work completed and total scope. It is the one standard agile chart that makes scope change visible. When work is added, the scope line rises. When work is removed, it falls. A burndown folds that change into a single line; a burn up shows it. That is why so many teams prefer it for release tracking, and they are right to.
It is also fair to the team. The completed-work line only goes up, so nobody looks unproductive when stakeholders add work. The gap between the two lines is the work remaining.
What it leaves out
A step in the scope line tells you that scope changed. It does not tell you what that change costs the committed release date, in days, or what it does to the team’s confidence in that date.
The usual workaround is a ruler: extend the completed-work line until it meets the scope line and read off a date. That gives one date with no confidence level, and it assumes throughput stays constant for the rest of the release. It rarely does. Holidays, a key engineer on leave and a blocking dependency from another team all bend the line. None of them appear on the burn up chart.
Jira’s built-in Burnup report adds one more limit: it is scoped to a sprint. A committed release date usually spans many sprints and lives on a Fix Version. Sprint by sprint, each step in scope looks small. Across the release, they add up.
The vote was right. Then the release kept moving.
When a team takes a confidence vote on a committed date, that vote is expert engineering judgment. It was right on the day it was taken, given the scope, capacity and dependencies the team could see. The team owns those assumptions: which throughput window reflects how they work, whose capacity counts, what is in and out of scope.
What changes the date afterwards is the three things that erode a release date: scope creep, dependencies surfaced too late, and capacity changes. The burn up chart shows the first. It is silent on the other two, and it never converts any of them into days against the date the team committed to.
That is the difference between a snapshot and a live number. The burn up chart is a better snapshot than most, because it shows the scope line moving. It still leaves someone to guess what the movement means.
Pricing the scope line in days
Keep the burn up chart. Add a forecast that re-runs every time the scope line moves.
An illustration: a team commits to 14 June at 85% confidence. Over five weeks, scope grows 18%. On the burn up chart, that is three modest steps. Run the same history through a Monte Carlo forecast, using the team’s own throughput and configured capacity, and the picture becomes concrete: confidence at 14 June has fallen to 61%, and the P85 date now sits 9 days later. A product owner can act on that in week five, not week eleven.
It also turns the conversation from blame to options. Nine days might be recovered by moving two Should-haves below the cut line, by resequencing a dependency, or by renegotiating the date with stakeholders who can see why. Each option is a trade the team makes on evidence it has validated.
How Advanced Release Planning keeps the burn-up live
Advanced Release Planning for Jira draws the release burn-up per Fix Version, not per sprint. Scope moves both ways: work added and work removed is recorded whether it changes in the app or through the Fix Version field in Jira. Scope change is shown as a rate, a percentage and a per-day pace, so “creep” becomes a figure. Every scope change feeds the Monte Carlo simulation, so the committed date is carried with its confidence band (P50, P85, P95) and the gap is measured in days.
The same forecast accounts for configured capacity and dependency links against the committed date. The team still owns the assumptions. The app does the arithmetic at scale and keeps it current between planning events. For the reference detail, see Burn Up Charts & the Committed Release Date: What the Forecast Adds.
If your team already reads a velocity chart or a milestone chart, the pattern is the same: the chart shows what happened; the forecast says what it costs the date.
Key takeaways
- A burn up chart shows scope change. It does not price that change against the committed release date.
- A ruler projection gives one date, no confidence, and assumes constant throughput.
- Scope creep, late dependencies and capacity changes erode a committed date after the vote. The burn up chart shows only the first.
- Carry the committed date with a live confidence band and measure the gap in days, so the team renegotiates before it slips.
FAQ
What is the difference between a burn up and a burn down chart?
A burndown plots work remaining, so added scope is folded into one line. A burn up plots completed work and total scope as separate lines, so scope changes are visible.
Can a burn up chart forecast a release date?
Only as a straight-line projection with no confidence level. A Monte Carlo forecast uses throughput variability, capacity and dependencies to give a date range, such as P50, P85 and P95.
The scope line moved. Find out what it cost. See your committed date and its live confidence band in Advanced Release Planning, or try it on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.