A burn up chart is a visual tool used in project management that tracks completed work against total project scope over time. It plots two lines on a simple graph: one showing how much work the team has finished so far, and another showing the total amount of work the project requires. When the project is done, those two lines meet. This makes it easy to see at a glance how close a team is to finishing and whether the goal line itself has moved.
How a Burn Up Chart Works
The chart uses two axes. The horizontal axis (x-axis) represents time, typically measured in days or sprints. The vertical axis (y-axis) represents the amount of work, which teams can measure in story points, issue counts, or hour estimates, depending on how they track their backlog.
Two main lines run across the chart. The scope line sits at the top and represents the total work required to complete the project. The completed work line starts at the bottom left and climbs upward as the team finishes tasks. Some teams also add a third line showing the ideal pace, a straight diagonal that represents the rate at which the team would need to work to finish on schedule. Comparing actual progress against that ideal pace line tells you quickly whether you’re ahead, behind, or on track.
Before you can create the chart, you need a reasonably defined project scope. That means identifying all the tasks in the backlog and assigning each one a size estimate. Once you have that total, you plot the scope line and begin updating the completed work line at regular intervals, usually at the end of each day or sprint.
Why Scope Visibility Matters
The biggest advantage of a burn up chart is that it makes scope changes visible. In many projects, especially software development, requirements evolve over time. Stakeholders add features, edge cases surface during testing, or priorities shift. When that happens, the scope line on a burn up chart moves upward. You can literally see the target getting farther away.
This is valuable because it separates two very different problems. If the completed work line is climbing slowly, the team has a velocity issue. If the scope line keeps rising, the project has a scope creep issue. Without a burn up chart, both problems look the same from the outside: the project is late. With the chart, you can pinpoint the actual cause and address it directly. A project manager can walk into a meeting, point to a rising scope line, and show stakeholders exactly when new requirements were added and how they pushed out the timeline.
Burn Up vs. Burn Down Charts
A burn down chart works in the opposite direction. It starts with the total work at the top and shows a line descending toward zero as the team completes tasks. Both charts track progress, but they handle scope changes differently. A burn down chart has only one line, so when scope increases, the line jumps back up. That can look confusing, like the team suddenly lost progress, when in reality the goalposts just moved.
A burn up chart separates scope and progress into two distinct lines, so it tells a clearer story when requirements change. For projects with stable, well-defined scope, a burn down chart works fine. For projects where scope changes frequently, or where you need to communicate progress to stakeholders who aren’t involved in day-to-day work, a burn up chart gives a more complete picture. It shows both how much has been done and how much there is to do, without one obscuring the other.
How to Build One
You can create a burn up chart in a spreadsheet, a whiteboard, or a project management tool like Jira, Azure DevOps, or similar platforms that generate them automatically from your backlog data. Here’s the basic process if you’re building one manually:
- Define your units. Decide whether you’ll measure work in story points, number of issues, or time estimates. Story points are common in agile teams because they account for complexity, not just hours.
- Calculate total scope. Add up the estimated size of every item in the backlog. This becomes your initial scope line, which you plot as a horizontal line across the chart.
- Track completed work. At the end of each sprint or time period, add up the total points (or issues, or hours) the team has finished since the project started. Plot that cumulative total as a point on the completed work line.
- Update scope when it changes. If new work is added to the backlog, recalculate total scope and adjust the scope line upward. If items are removed, adjust it downward.
The key word is “cumulative.” Unlike a velocity chart that shows output per sprint, the completed work line on a burn up chart always goes up or stays flat. It never goes down, because it represents everything finished to date. This upward trajectory is part of what makes the chart motivating for teams. You can always see how far you’ve come, not just how far you have left to go.
Reading the Chart in Practice
Once your burn up chart has a few data points, patterns emerge. If the completed work line is climbing at a steady angle and the scope line is flat, the project is on a predictable path. You can extend the completed work line forward to estimate when it will intersect the scope line, giving you a projected completion date.
If the scope line keeps rising at a rate close to the team’s velocity, the two lines will never converge. That’s a clear signal that the project will not finish unless scope is cut or capacity is added. This scenario is surprisingly common and often invisible without a chart that tracks both variables.
A flattening completed work line, where it goes horizontal for a period, indicates the team stopped delivering. That could mean blockers, competing priorities, or underestimated tasks. Combined with the scope line, you get a full diagnostic view of project health in a single image.
When to Use a Burn Up Chart
Burn up charts are most useful in longer projects with multiple sprints or phases, where scope is likely to evolve. They’re a natural fit for agile software development, but they work equally well for marketing campaigns, product launches, or any project where you can break the work into countable, estimable pieces.
They’re also particularly effective for stakeholder communication. A burn up chart requires no technical knowledge to read. Anyone can look at two lines on a graph and understand whether they’re getting closer together or farther apart. That simplicity makes it one of the most accessible ways to report project status without burying people in spreadsheets or status updates.