Burn Up Chart in Agile Product Management
Product Management
Learn how burn up charts help track progress and scope changes in Agile product management effectively.
Scope changes happen in almost every sprint and release. The problem is that most tracking charts hide those changes, making it look like progress simply slowed down when the real issue was that the target moved.
A burn up chart in Agile product management is a visual graph that shows completed work increasing toward the total project or sprint scope. Unlike a burn down chart, it makes scope changes visible as a separate line, revealing both progress and shifting targets at the same time.
Key Takeaways
- Shows completed work, not remaining work: the burn up line rises from zero toward the total scope line, making progress feel tangible and visible to the whole team.
- Scope changes are transparent: when new work is added, the total scope line moves up, clearly showing that the target changed rather than that the team fell behind.
- Two lines tell the full story: the completed work line shows actual progress; the total scope line shows how much has been committed and whether that commitment has grown.
- Better for longer planning horizons: burn up charts are particularly useful for release-level tracking where scope additions are more common than in a single sprint.
- Easier for stakeholders to understand: executives and stakeholders often find the rising completed work line more intuitive than the falling remaining work line of a burn down chart.
- Not better or worse than burn down, just different: each chart answers a different question; many teams use burn down for sprints and burn up for releases.
What is a Burn Up Chart in Agile?
A burn up chart tracks completed work over time using two lines: a rising completed work line and a flat or rising total scope line. The goal is for the completed work line to reach the total scope line by the target date, showing the team has finished everything planned.
Burn up charts became popular because they answer a question burn down charts cannot: was progress slow because the team worked less, or because someone added more work mid-stream?
- The x-axis shows time: days in a sprint or sprints in a release are plotted along the horizontal axis.
- The y-axis shows work in story points or tasks: both the completed and total scope values are plotted on the same scale along the vertical axis.
- The completed line always rises: work can only move from incomplete to complete, so this line should trend upward across the sprint or release period.
- The scope line may rise if work is added: any new stories or tasks added to the commitment show as an upward shift in the total scope line, making additions transparent.
Atlassian's burn up chart documentation explains how to configure and read burn up charts within Jira and how to interpret the two lines together.
How is a Burn Up Chart Different from a Burn Down Chart?
A burn down chart shows remaining work falling toward zero. A burn up chart shows completed work rising toward total scope. Both track the same sprint or release progress, but burn up charts make scope changes visible while burn down charts absorb scope additions invisibly into the remaining work count.
Choosing between the two charts depends on what question the team most needs to answer at any given time in the planning cycle.
- Burn down answers "how much is left to do": it is fast to read and immediately shows whether the sprint is on track, making it popular for daily sprint monitoring.
- Burn up answers "how much have we done and has the scope moved": it is more informative for multi-sprint tracking where stakeholder additions to scope are common.
- Scope changes are hidden in burn down charts: if 10 points of new work are added to a sprint, the burn down line stays flat rather than revealing that the target grew.
- Burn up charts make stakeholder scope creep visible: when leadership adds requirements mid-release, the rising scope line makes that addition visible to everyone, not just the team.
Understanding when each chart type applies is part of choosing the right Agile metrics for your team's planning context and communication needs.
When Should a Product Team Use a Burn Up Chart?
Use a burn up chart when scope changes are frequent, when you need to communicate progress to stakeholders who may add requirements, or when tracking a release plan that spans multiple sprints. Use a burn down chart when scope is stable and the team just needs daily sprint visibility.
Burn up charts shine in contexts where transparency about scope changes matters more than simplicity of tracking.
- Release-level tracking benefits most from burn up: releases span weeks or months, during which stakeholder requests often add to the scope, making the two-line view essential.
- Stakeholder communication is clearer with burn up: when presenting progress to non-technical stakeholders, the visual of completed work growing toward a target is intuitive and honest.
- Scope-stable sprints may not need burn up: if your sprint commitment never changes once set, the added complexity of a two-line chart provides less additional value.
- Teams managing multiple contributing projects use burn up: tracking progress toward a shared release goal from parallel workstreams is easier with a burn up chart than with separate burn downs.
Some teams use burn up charts as part of a broader portfolio management approach where multiple product lines contribute to a shared release or business objective.
How Do You Read a Burn Up Chart?
To read a burn up chart, watch whether the completed work line is rising fast enough to meet the total scope line by the target date. If the completed line is rising slower than needed, the team will miss the target. If the scope line is rising, new work has been added and needs to be discussed.
Reading a burn up chart is about tracking two relationships simultaneously: how fast progress is happening and whether the target is moving.
- Lines converging toward the target date signal healthy progress: when completed work and total scope are on track to meet at the end of the sprint or release, the plan is on course.
- A rising scope line with no increase in velocity signals a problem: if scope grows but pace does not, the release date will slip unless something is deprioritized or added capacity is found.
- A flat completed line for multiple days signals a blocker: just like in burn down, a period of no completed work suggests the team is stuck and needs help surfacing the obstacle.
- Meeting scope before the deadline means the team overestimated: if completed work reaches total scope early, the sprint had more capacity than was committed to, and future planning can adjust for that.
At LOW/CODE Agency, we've helped 450+ clients build and scale digital products. Our clients include global brands like Medtronic, American Express, Coca-Cola, Zapier, and Sotheby's.
Conclusion
Burn up charts are a small change in how you visualize progress that creates a significant improvement in transparency, especially when stakeholders are involved and scope is not fixed. By separating completed work from total scope into two distinct lines, they make accountability visible for everyone in the room.
Whether a team uses burn down, burn up, or both depends on what they are tracking and for whom. The right chart is the one that makes the team's most important questions easy to answer at a glance.
FAQs
What is a burn up chart in simple terms?
What is the main difference between burn up and burn down charts?
When should you use a burn up chart instead of a burn down chart?
What do the two lines on a burn up chart represent?
Can you use both burn up and burn down charts on the same team?
What does it mean if the scope line on a burn up chart keeps rising?
Related Terms
See our numbers
315+
entrepreneurs and businesses trust LowCode Agency
Investing in custom business software pays off
I'm honestly blown away by how good this is. What used to be a manual process in spreadsheets now feels cleaner, more accountable, and much easier to manage. I'm so grateful for the direction we're headed.
$40K
Reallocated to operations each year
1,500
Hours recovered per year
Jordan Katon
,
Vice President of Operations at Rising Ground
Rising Ground Fleet Portal

%20(Custom).avif)