IPM CPM Level 1
hamburger__close
A burn up chart is an Agile tracking tool that shows completed work climbing toward a total project scope, giving teams a clearer picture of progress than a burndown chart alone, particularly when scope is likely to change mid-sprint or mid-project. This guide explains what a burn up chart is, how to read and build one, and when it earns a place alongside, or instead of, a burndown chart.
A burn up chart plots two lines against time: a total scope line, showing the full amount of work committed to a sprint or project, and a completed work line, which rises steadily as the team finishes tasks. Unlike a burndown chart, which only shows work remaining, a burn up chart separates progress from scope, making it possible to see at a glance whether a project is falling behind because the team is underperforming or because scope has genuinely grown.
When the completed work line rises steadily and eventually meets the total scope line, the sprint or project is on track to finish as planned. If the total scope line itself steps upward partway through, that is a direct, visual signal that new work has been added, something a burndown chart would simply show as slower-than-expected progress without explaining why. This makes burn up charts especially valuable for stakeholders who need to understand the difference between a team working slowly and a project whose goalposts have moved.
Start by plotting the total scope of work, in story points, hours, or task count, as a flat horizontal line representing the full commitment. Each day or iteration, plot the cumulative amount of completed work as a second, rising line beneath it. If scope changes, the total scope line is redrawn upward or downward at that point, preserving a visible record of when and by how much the target moved. Most Agile project tools, including Jira and Azure DevOps, can generate burn up charts automatically once a team is logging completed story points against a defined backlog.
Advance your career with our Agile Project Management dual certification programme, offering practical skills to meet modern project demands.
The two charts plot the same underlying delivery data in opposite directions. A burndown chart tracks remaining work falling to zero, which is intuitive for a fixed-scope sprint but can hide scope changes. A burn up chart tracks completed work rising toward a scope line that can itself move, which makes it the better choice for programmes and product teams where scope is expected to evolve. Many teams use a burndown chart for sprint-level tracking and a burn up chart for release or programme-level tracking, applying each where its strengths matter most.
A burn up chart is the stronger choice whenever scope is genuinely likely to change during the tracking period, such as in product development, longer release cycles, or programmes where stakeholders regularly add or reprioritise work. It is also useful when reporting to senior stakeholders who need to understand not just whether a team is behind, but whether that is because of team performance or because more has been asked of them since the plan was set.
Earn a Scrum Master certification through our Professional Scrum Master Training, preparing you to excel in a Scrum environment.
With 74% of Agile teams now running blended, hybrid, or homegrown delivery approaches rather than a single framework applied strictly by the book1, scope stability can no longer be assumed the way classic Scrum theory suggests. A burn up chart gives UK delivery teams and PMOs a more honest reporting tool in that reality, one that separates the story of team performance from the story of shifting scope, which matters enormously when reporting progress to steering committees.
At programme and portfolio level, where multiple teams and workstreams contribute to a shared release, a burn up chart becomes particularly valuable because it can aggregate completed work across teams while still showing the combined scope line moving as new commitments are added or removed at portfolio review points. This makes it a natural reporting tool for PMO functions that need to show senior stakeholders not just raw percentage-complete figures, but a defensible visual explanation for why a programme’s completion date has shifted, distinguishing genuine delivery slippage from stakeholder-driven scope growth.
Most mainstream Agile project management tools, including Jira, Azure DevOps, and Monday.com, offer native or plug-in support for burn up charts, typically generated automatically once a team logs a backlog with estimated effort and marks items complete over time. Teams without access to these platforms can build a serviceable burn up chart in a spreadsheet by maintaining two running columns, cumulative scope and cumulative completed effort, and plotting both against date. While less automated, a spreadsheet-based burn up chart still delivers the same core benefit: an honest, visual separation between team output and shifting scope.
One of the most underrated benefits of a burn up chart is how it reframes difficult stakeholder conversations. When a project falls behind on a burndown chart alone, the natural stakeholder question is “why is the team not delivering fast enough?”, which can feel accusatory and puts delivery teams on the defensive even when the real cause is scope growth outside their control. A burn up chart shifts that conversation entirely: when the scope line has visibly stepped upward, the natural question becomes “which of these newly added items should we deprioritise to protect the original date?”, a far more productive framing that keeps the stakeholder engaged in trade-off decisions rather than simply demanding faster delivery of an ever-expanding target.
| Aspect | What to Know | Why It Matters |
| Purpose | Tracks completed work against a scope line | Separates team performance from scope change |
| Two lines | Total scope line and completed work line | Scope-line movement reveals changing requirements |
| Best used for | Programmes, releases, evolving product scope | More resilient than burndown when scope shifts |
| vs Burndown | Shows scope changes explicitly | Burndown can hide them entirely |
| Tools | Jira, Azure DevOps, spreadsheets | Most auto-generate once backlog and completions are logged |
Teams building their first burn up chart benefit from a simple, disciplined setup process. Start by defining the full backlog of work in scope for the release or sprint and estimating it consistently, in either story points or hours, so the total scope figure is meaningful. Next, choose a reporting cadence, daily for sprint-level tracking or weekly for programme-level reporting, and commit to updating the chart at that same interval without exception, since gaps in reporting are the most common reason burn up charts fall out of use. Establish a clear process for how scope changes are captured: any addition or removal of backlog items should be logged with a date, so the scope line’s movement can always be explained in a stakeholder conversation. Finally, review the chart at every sprint or stage review, not just when problems arise, so it becomes a habitual part of how the team communicates progress rather than a tool reached for only during a crisis.
Consider a product team starting a release with 100 story points of committed scope. By the midpoint of the release, the team has completed 40 points, and the completed-work line sits comfortably on track to reach 100 by the deadline. Midway through, a critical stakeholder request adds a further 20 points of newly discovered work. On a burndown chart, this would simply appear as the team suddenly falling behind, with no visible explanation. On a burn up chart, the total scope line visibly steps up from 100 to 120 points at the exact point the change was introduced, while the completed-work line continues its steady climb beneath it. Anyone reviewing the chart can immediately see that the team’s actual delivery rate has not changed at all; the target itself simply moved, a distinction that materially changes the conversation with stakeholders about whether the release date needs to shift.
A burn up chart earns its place in a modern Agile toolkit precisely because real projects rarely have perfectly fixed scope. By tracking completed work against a scope line that can move, it gives UK teams and stakeholders a more honest, complete picture of delivery progress than a burndown chart can offer on its own.
A burn up chart separates completed work from total scope, making scope changes visible as a moving target line rather than hidden inside a slower-than-expected burndown.
Yes, and many mature Agile teams do, using a burndown chart for sprint-level tracking and a burn up chart for release or programme-level reporting where scope is more likely to shift.
Yes, though Kanban teams more commonly use a cumulative flow diagram, which is a close relative of the burn up chart adapted for continuous flow rather than fixed sprints.
Any addition, removal, or re-estimation of backlog items during the tracking period moves the total scope line up or down, giving a transparent record of when requirements changed.
Sprint-level burn up charts are best updated daily alongside the team’s stand-up, while programme or release-level charts are typically updated weekly or at each formal stage review, matching the cadence at which stakeholders expect progress updates.
