Burnup Chart: What It Is and How to Read One

A burnup chart is a graph that plots completed work rising toward a separate line showing total scope. Instead of one number telling you "how much is left," it gives you two: how much the team has finished, and how much work exists to finish in the first place.

That second line is what a burndown chart can't give you on its own. A burndown line falling toward zero looks the same whether the team is genuinely closing in on done or the scope just shrank. A burnup chart separates those two stories instead of blending them into one descending line.

Key Facts

• The 2020 Scrum Guide names burn-ups directly alongside burn-downs and cumulative flow diagrams as practices teams use "to forecast progress," while noting these "do not replace the importance of empiricism."
• PMI's Pulse of the Profession 2026 found that roughly a third of complex projects fail, "nearly twice the 13% rate of failure for projects overall," a gap a rising scope line makes visible early rather than at the postmortem.
• The PMBOK Guide, Eighth Edition (PMI, November 2025) lists scope as one of seven performance domains, the same variable a burnup chart's ceiling line tracks in real time as work is added or removed.
• PI Planning, the SAFe practice that aligns an entire Agile Release Train, runs every 8-12 weeks as a 2-day event, the natural cadence for a release-level burnup spanning a full Program Increment.

What is a burnup chart? The two lines explained

A burnup chart has an X-axis for time (days, iterations, or sprints) and a Y-axis for work, usually story points, hours, or item counts. Two lines sit on that grid, and each one answers a different question.

The completed line only moves up. Once work counts as done, it stays counted, so the line can plateau on a slow day but it never falls back down the way a burndown line does. The scope line is the one that carries the news. When it's flat, the team is working against a fixed target. When it steps upward mid-sprint, someone added work. When it steps down, someone descoped something, intentionally or not.

Both lines start on the same day and, in a healthy project, they meet. The moment the completed line touches the scope line is the moment the work is actually finished, not just close to it. The format shows up most often on teams running Scrum, though nothing about the chart is Scrum-specific: any team tracking work against a total can use one.

Reading the gap between the lines

The vertical distance between the two lines at any point in time is remaining work. That's the number a burndown chart shows directly as its single line; on a burnup chart, you read it as a gap instead.

A shrinking gap is good news only if both lines are moving the way you expect. A gap that shrinks because the scope line dropped, not because the completed line rose, is a different and less reassuring story, and the two-line format is what lets you tell them apart.

Sprint burnup vs release burnup

Like burndown charts, burnup charts come in two common scopes. They serve different audiences and update on different clocks.

Release-level burnups are the more natural fit for the chart type, because release scope changes far more often than sprint scope should. Programs running under the Scaled Agile Framework often plot a burnup across a full Program Increment, refreshed at each iteration boundary between PI Planning events, which recur roughly every 8-12 weeks and align every team on the Agile Release Train to the same scope going in. Unlike a milestone chart, which tracks dates rather than volume of work, a burnup chart's X-axis moves in the same units as its Y-axis: work against work, not work against a calendar.

The scope line: your built-in scope-creep detector

This is the feature a burndown chart structurally can't match. A burnup chart's total scope line is a direct, continuous record of every addition and removal, and scope creep shows up as a shape you can point to instead of a story someone has to reconstruct after the fact.

Because the scope line records every change permanently on the same axis as delivered work, a burnup chart makes the classic "we didn't actually get slower, the target moved" conversation something you can settle by pointing at the chart instead of arguing from memory. That's a direct extension of scope as one of the seven performance domains named in the PMBOK Guide, Eighth Edition: the burnup chart is one way of keeping that domain visible day to day rather than only at a phase gate.

Four readable patterns

Reading a burnup chart is a matter of watching how the two lines move relative to each other over time. Four shapes come up often enough to name.

Pattern 1: Tracking together

The completed line rises at a roughly consistent rate and the scope line stays flat. The gap narrows smoothly and the two lines are set to meet on or near the deadline. This is the shape every team wants, and it means estimation and capacity were reasonably matched going in.

Pattern 2: Completed line flattening

The scope line stays flat, but the completed line plateaus for a stretch instead of continuing to climb. Work isn't getting finished, though the target hasn't changed. This usually points to a blocker, a definition-of-done bottleneck (code sitting in review, QA backed up), or work that's in progress but not yet countable as complete. Check the daily standup notes from that window before assuming the team simply slowed down.

Pattern 3: Scope line climbing

The completed line keeps a steady pace, but the scope line steps upward one or more times. The gap between the lines doesn't close the way it should, not because the team is underperforming, but because the target moved. This is the pattern that a burndown chart would show as a confusing upward spike in an otherwise descending line; on a burnup chart it's unambiguous, because the scope line itself carries the change.

Pattern 4: Both lines converging early

Completed work catches the scope line before the deadline, and the two lines run flat together for the remaining time. Either the team finished ahead of schedule, or the scope was underestimated from the start. Worth a quick gut check in the sprint review: if this happens often, capacity planning is leaving too much slack, and the team could be taking on more per cycle.

Burnup chart examples by team

The shapes above show up differently depending on the kind of work and how often scope realistically changes.

Program-level burnups see the most scope-line movement almost by design: a Program Increment spans multiple teams and multiple PI Planning cycles, and new features regularly enter as later increments come into clearer focus.

How to build a burnup chart: step by step

Step 1: Define your total scope

Before you plot anything, list everything currently committed to the sprint, release, or project, and total it in your chosen unit (story points, hours, or item count). This total is your starting scope-line value, and it should match whatever the team agreed to during sprint planning or the equivalent kickoff for a release.

Step 2: Set up the axes

Time goes on the X-axis (days, sprints, or iterations depending on scope). Work goes on the Y-axis, running from zero to comfortably above your current total scope, since that line may still climb. Label both axes with their units so nobody has to guess whether a data point means points, hours, or stories.

Step 3: Plot the scope line first

Place a point at your Day 0 total scope value, then extend it flat across the chart. This line only moves when scope actually changes, not on a schedule. Every time work is added, mid-sprint or mid-release, add a new point that steps the line up on that date. Every time work is removed, step it down.

Step 4: Plot the completed work line daily (or per iteration)

At the same cadence you update the scope line, record cumulative completed work: the running total of everything finished so far, not just what finished that day. This line should never decrease. If something marked "done" later gets reopened, that's a data-quality problem worth flagging in the daily standup, not something to quietly erase from the chart.

Step 5: Interpret both lines together, not separately

A burnup chart earns its keep in the conversation it triggers, not in the chart itself. Is the gap closing at a pace that will hit the deadline? Did the scope line move, and was that change agreed to or did it slip in unnoticed? Pair the reading with velocity from past sprints to judge whether the current pace is realistic, not just whether it looks steep enough on the page.

Burnup chart vs burndown chart: when each is the better instrument

Our burndown chart guide covers this comparison from the burndown side; here's the fuller picture from the burnup side, and the two should agree with each other.

The Scrum Guide treats both as peers rather than ranking one above the other. It names "burn-downs, burn-ups, or cumulative flows" together as practices used to forecast progress, with the same caveat attached to all three: they inform decisions, they don't replace the ongoing inspection and adaptation that Scrum is actually built on. Teams new to tracking usually start with burndowns because one line is simpler to explain. Teams that keep having arguments about "did scope change or did we just get slower" tend to move to burnup charts once that argument happens for the third or fourth time.

What a burnup chart can't tell you

A burnup chart is a scope-and-progress instrument. It isn't built to answer everything, and treating it as a complete health dashboard leads to blind spots.

None of these gaps are unique to burnup charts. Every progress-tracking chart trades detail for a fast, glanceable read. The fix isn't to abandon the chart, it's to know which follow-up question to ask when the two-line picture stops being enough on its own.

Common mistakes (and how to fix them)

Best practices

• Update both lines on the same schedule. A burnup chart with a fresh completed line and a stale scope line gives a false sense of how much is really left.
• Record scope changes the moment they happen, not at sprint end. Retroactively reconstructing when work was added defeats the purpose of the scope-creep detector.
• Share the chart with stakeholders, not just the delivery team. The scope line is often more useful to a Product Owner managing expectations than to the engineers doing the work.
• Use release-level burnups for anything spanning more than a couple of sprints. Sprint-level burnups matter for the team; release-level burnups matter for the promise made to the business. Keep the final chart, too: the finished scope line is the cleanest evidence of what was actually delivered against what was committed, which is exactly what project closure asks you to prove at handover.
• Pair the chart with velocity data, not just the current trend line. A burnup chart tells you where you are. Velocity over several past sprints tells you whether the pace you're seeing is normal.
• Don't let a flat scope line become the goal in itself. Zero scope change isn't automatically healthy if it means real, necessary requirements are being deferred to a future release instead of handled now.
• Bring the chart into the sprint review, not just the retrospective. Stakeholders who see the scope line move in real time argue less about "why isn't this done yet" after the fact.
• Keep the total scope line's full history, not just the latest value. A chart that only shows the current line loses the step-by-step record that makes scope changes defensible and explainable later.

A burnup chart earns its place on the dashboard the first time a stakeholder asks why a sprint "isn't going faster" and the answer is sitting right there in a scope line that stepped up twice since the last review. Start with a sprint-level burnup if your team is new to the format, and move to release-level tracking once you're managing work that spans more than a couple of sprints. Either way, the two lines do something one line never could: they let you show your work and show what got added to it, on the same chart, at the same time.