What is a Burn-Up Chart & How to Read It

Your sprint review meeting starts in ten minutes. The product owner pulls up a burn-down chart and asks: "Are we on track?" The line trends downward, and the team nods. But nobody mentions that the scope expanded by 15 story points mid-sprint because the client added a new payment gateway requirement. The burn-down chart hides this completely. A burn-up chart would have shown it in seconds.

This is exactly why burn-up charts exist. They solve a specific blind spot in agile project tracking: making scope changes visible alongside progress. If you have ever finished a sprint feeling productive yet somehow further from "done" than when you started, you already understand the problem burn-up charts fix.

What is a Burn-Up Chart?

A burn-up chart is a visual tool that plots two lines on a graph over time. The horizontal axis represents time, usually in sprints or days. The vertical axis represents effort, typically measured in story points, tasks, or hours. The two lines are:

• Work Completed: starts at zero on day one and climbs upward as the team finishes work
• Total Scope: represents the full amount of work planned for the project or release

When the completed work line meets the scope line, the project is done. The gap between the two lines tells you how much work remains at any point.

The critical difference from a burn-down chart is that second line. A burn-down chart only shows remaining work trending toward zero, which means scope changes are invisible. If you add 20 story points of work and complete 20 story points in the same sprint, a burn-down chart looks flat. A burn-up chart shows both events clearly: the scope line jumps up and the completed line climbs to match.

Burn-Up vs. Burn-Down: When Each Makes Sense

Burn-down charts are not useless. For a single two-week sprint with locked scope, a burn-down works perfectly well. The scope is fixed, the remaining work trends toward zero, and the team can see if they are ahead or behind their ideal pace line.

Burn-up charts become essential when:

• You are tracking a release that spans multiple sprints
• Stakeholders regularly add or remove requirements
• You need to communicate project health to non-technical executives
• You want to forecast completion dates based on velocity trends
• Your team works on a product with evolving requirements

Here is a practical comparison. A SaaS startup building a mobile app planned 200 story points for their MVP release across 10 sprints. After sprint 4, the CEO attended a conference and came back with "must-have" features: push notifications, dark mode, and offline sync. That added 65 story points.

On their burn-down chart, the remaining work line suddenly jumped upward. The team looked like they had gone backward. Morale dropped. Stakeholders panicked.

On a burn-up chart, the same situation tells a clearer story. The completed work line kept climbing steadily at about 22 points per sprint. The scope line jumped from 200 to 265 after sprint 4. Anyone looking at the chart could immediately see: the team is performing consistently, but the goalposts moved. That distinction matters enormously for team trust and stakeholder confidence.

How to Read a Burn-Up Chart: A Step-by-Step Walkthrough

Reading a burn-up chart takes about 30 seconds once you know what to look for. Here is how to interpret each element.

Step 1: Check the Gap Between the Lines

The vertical distance between the scope line and the completed work line is your remaining work. A shrinking gap means you are converging on completion. A growing gap means scope is expanding faster than your team delivers. A constant gap means scope and delivery are increasing at the same rate, which sounds okay but actually means you will never finish.

Step 2: Look at the Slope of the Completed Work Line

The slope of the completed work line is your team velocity made visual. A steady upward slope means predictable delivery. Flattening indicates the team slowed down, possibly due to technical debt, dependencies, or team members being pulled to other work. Steepening means the team accelerated, maybe because blockers were removed or a new team member ramped up.

Step 3: Examine Scope Line Movements

Every jump in the scope line represents a scope change. Upward jumps mean new work was added. Downward drops mean requirements were removed or descoped. Frequent small jumps suggest requirements are being discovered iteratively, which is normal in agile. Large sudden jumps signal a stakeholder decision or a missed requirement, which is worth discussing in your retrospective.

Step 4: Project the Finish Date

Extend the completed work line forward at its current slope. Where it intersects the scope line is your projected completion date, assuming scope stays constant. If the scope line has been trending upward, extend that trend too. The intersection of both projected lines gives a more realistic forecast. This is far more honest than a burn-down chart that assumes scope is fixed.

Building a Burn-Up Chart: Practical Setup

You do not need specialized software to create a burn-up chart, though tools like Jira, ClickUp, and Monday.com generate them automatically from your sprint data. Here is how to build one manually in a spreadsheet.

The Data You Need

Create a table with four columns:

• Sprint or Date: your time intervals
• Total Scope: cumulative story points or tasks planned
• Completed Work: cumulative story points or tasks finished
• Remaining: calculated as Total Scope minus Completed Work

Here is what real data looks like for a 10-sprint release:

Sprint 1: Scope 120, Completed 18, Remaining 102

Sprint 2: Scope 120, Completed 40, Remaining 80

Sprint 3: Scope 120, Completed 65, Remaining 55

Sprint 4: Scope 145 (scope added), Completed 87, Remaining 58

Sprint 5: Scope 145, Completed 112, Remaining 33

Sprint 6: Scope 140 (scope reduced), Completed 132, Remaining 8

Notice how sprint 4 shows scope expanding from 120 to 145, and sprint 6 shows scope shrinking from 145 to 140 after the team negotiated descoping a low-priority feature. Both events are immediately visible.

Choosing Your Unit of Measurement

Story points are the most common unit for burn-up charts, but they are not the only option:

• Story points: best when your team has calibrated estimates and consistent velocity
• Task count: simpler to track, works well when tasks are roughly similar in size
• Ideal hours: useful for teams that have not adopted story points
• Features or user stories: good for executive-level reporting where granularity matters less

Pick one and stick with it for the duration of a release. Mixing units makes the chart meaningless.

Common Patterns and What They Mean

The Converging V

The scope line stays flat or trends slightly downward while the completed line climbs steadily. This is the ideal pattern. It means requirements are stable, the team is delivering consistently, and you will hit your release date. If you see this shape, your biggest risk is complacency. Keep running your standups and retrospectives.

The Expanding Funnel

The scope line climbs faster than the completed work line, creating a widening gap. This is the danger signal. It means new requirements are being added faster than the team can deliver. You will never finish unless you either freeze scope or add capacity. This pattern is common in projects where stakeholders skip backlog refinement meetings and dump requirements ad hoc. Address it immediately in your next sprint planning session.

The Parallel Lines

Both lines climb at roughly the same rate, maintaining a constant gap. The team is delivering, but scope keeps growing at the same pace. This often happens in maintenance-heavy products where every feature shipped creates follow-up requests. The fix is usually better backlog grooming: not every request needs to be in the current release.

The Plateau

The completed work line flattens while scope stays constant. The team stopped delivering. This could signal a major blocker, key team members leaving, technical debt paydown (which does not produce visible story points), or simply a holiday period. Investigate the root cause rather than assuming the worst.

The Staircase

The completed line jumps up in large steps with flat periods between them. This usually indicates the team delivers in large batches rather than continuously. You might see this when work items are too large (an epic counted as a single item) or when the team waits to mark items complete until the end of a sprint. Smaller work items and more frequent updates produce a smoother, more useful chart.

Using Burn-Up Charts in Your Tools

Most modern project management platforms generate burn-up charts automatically.

Jira

Jira offers a native burn-up report in its board settings under "Reports." It pulls data directly from your sprint backlog and tracks story points by default. The chart updates automatically as you move items across your board. Jira also lets you toggle between burn-up and burn-down views, making it easy to use whichever your stakeholders prefer.

ClickUp

ClickUp provides burn-up charts through its Sprint Dashboard widgets. You can configure them to track by story points, task count, or time estimates. ClickUp also supports velocity charts alongside burn-ups, which gives you the trend data you need for forecasting.

Monday.com

Monday.com does not have a dedicated burn-up chart widget, but you can build one using their chart view with two number columns: total planned and total completed. It requires slightly more manual setup than Jira or ClickUp, but the flexibility means you can customize it to match your exact tracking approach.

Spreadsheets

Google Sheets or Excel with a simple line chart works perfectly for smaller teams. Create a table with your sprint data and insert a line chart with two series. Update it at the end of each sprint. The advantage is full control over formatting and the ability to add annotations for scope change events.

Mistakes Teams Make With Burn-Up Charts

Not Updating Scope in Real Time

If you add stories to the backlog but do not update the total scope line, the chart becomes misleading. The completed line might reach the original scope target, making it look like the release is done when there are actually 30 more points of work. Update scope the moment new items are confirmed for the release, not at the end of the sprint.

Tracking Too Many Things on One Chart

A burn-up chart should track a single release, epic, or project. Combining multiple unrelated workstreams on one chart obscures the signal. If your team works on a product release and maintenance tickets simultaneously, create separate burn-up charts for each.

Ignoring the Chart Between Sprint Reviews

A burn-up chart is a living tool, not a reporting artifact. Check it during daily standups. Reference it in backlog refinement. Use it in stakeholder conversations when someone proposes adding scope. The chart becomes powerful only when the team treats it as a decision-making instrument.

Counting Partially Done Work

Only count work as completed when it meets your definition of done. If a story is 80% coded but not tested, it is zero on the burn-up chart. Counting partial work inflates the completed line and produces false optimism. This is the same discipline that makes velocity meaningful: done means done.

When to Skip the Burn-Up Chart

Burn-up charts are not always the right tool. Skip them when:

• You are running a single fixed-scope sprint with no stakeholder reporting: a simple task board is enough
• Your team is doing continuous delivery with no release batching: cumulative flow diagrams serve you better
• The project is under two weeks: the chart will not have enough data points to show meaningful trends
• You are a solo contributor: you already know your scope and progress intuitively

Burn-Up Charts and Agile Forecasting

One of the most practical uses of a burn-up chart is probabilistic forecasting. Instead of projecting a single completion date, draw multiple projection lines using different velocity assumptions:

• Optimistic: your best 3-sprint velocity average
• Likely: your overall average velocity
• Pessimistic: your worst 3-sprint velocity average

Where each projection intersects the scope line gives you a date range. Telling a stakeholder "we will finish between March 15 and April 2" is far more honest and useful than a single date that implies false precision.

This approach also makes trade-off conversations concrete. If the pessimistic projection overshoots your deadline by two weeks, you can show exactly how much scope needs to be cut for the likely projection to land on time. That turns a subjective negotiation into a data-backed discussion.

Getting Your Team to Actually Use Burn-Up Charts

The hardest part of burn-up charts is not creating them. It is getting people to look at them regularly. Here is what works:

• Display the chart on a shared screen or dashboard that the team sees daily
• Reference the chart in every sprint review and planning session
• Let the Scrum Master or project manager update it publicly during standups
• Annotate scope changes directly on the chart with brief explanations
• Celebrate when the lines converge, it is a visible sign of progress

Teams that embed the burn-up chart into their daily workflow use it. Teams that generate it once a sprint for a PowerPoint presentation ignore it. The chart is a communication tool, and communication only works when it is consistent.

Summary

Burn-up charts solve a specific problem: they show both progress and scope on the same visual, making scope changes transparent instead of hidden. They are most valuable for multi-sprint releases, projects with evolving requirements, and stakeholder communication where clarity matters more than simplicity.

The mechanics are straightforward: two lines on a graph, updated each sprint. The value comes from the conversations those lines enable. When a stakeholder asks to add scope, you can show exactly what that does to the timeline. When the team feels demoralized by moving goalposts, the chart proves they are delivering consistently even as the target shifts.

Start with your next release. Set up a simple spreadsheet or enable the burn-up report in your project management tool. Track scope and completed work for three sprints. By that point, you will have enough data to forecast, enough pattern recognition to spot problems early, and enough evidence to make the chart a permanent part of your process.