Burn ups: Agile burn up charts

If you’ve searched for “burn ups,” chances are you’re either tracking a software project or diving into nuclear engineering literature. This guide explains Agile project management.

Another common Agile project tracking tool is the burn down chart, which is often compared to burn up charts. We'll introduce the basic principles of burn down charts and discuss how they differ from burn up charts later in this guide.

What is a burn up chart in Agile?

A burn up chart is a visual tool that tracks completed work against total scope over time. Scrum and Kanban teams use it to visualize how close they are to finishing a release, sprint, or project. Unlike a burndown chart that starts high and decreases, a burn up chart starts at zero and rises as the team delivers. A burn down chart visualizes the remaining work over time, starting with the total scope and decreasing as work is completed, and is especially useful for projects with fixed scope.

A typical Agile burn up chart displays two lines on the same graph:

• The first line represents total scope—the amount of work planned for completion.
• The second line shows completed work, climbing steadily as the team finishes tasks.
• When these two lines meet, the project completed its scope. The gap between them at any point shows work remaining.

Teams measure progress using various units depending on their workflow, and the choice between story points vs. hours for estimation affects how you interpret the chart:

• Story points (most common in Scrum)
• Number of user stories or issues
• Tasks or work items
• Hours (less common in modern Agile)

The horizontal axis typically shows time in days, weeks, or sprints. For example, a product team might configure their x axis to display 10 two-week sprints spanning Q2 through Q4 2025.

Visual elements of an effective burn up chart:

• Clean grid with clear increments on both axes
• Distinct colors: blue or gray for scope line, green line for completed work
• A legend identifying each line
• Optional: dashed ideal pace line showing expected progress
• Y axis scaled appropriately (e.g., 0-200 story points in 20-point increments)

Figure 1: A sample burn up chart for a 6-sprint mobile app project would show a scope line starting at 100 story points, rising to 120 in sprint 3, with the progress line climbing from 0 to meet it by sprint 6.

Why and when to use burn up charts

Burn up charts are favored in Agile environments because they make project progress, scope changes, and completion forecasts visible at a glance. When stakeholders ask “how much work is left?” or “are we going to hit the deadline?”, a burn up chart answers both questions without lengthy explanations.

Key benefits of using burn up charts:

• Highlights scope creep: When the scope line jumps, everyone sees it immediately, giving product and engineering leaders clear evidence to apply structured scope creep management strategies.
• Forecasts completion dates: The gap between lines reveals how much work remains.
• Supports stakeholder communication: Product owners can show clear progress in sprint reviews.
• Simplifies status reporting: One chart replaces multiple slides or Gantt chart complexity.
• Reveals velocity trends: Steep progress slopes indicate high throughput.
• Separates progress from scope: Unlike burndowns, you see both factors independently.

Realistic usage scenarios:

• A SaaS team delivering a new billing system in Q3 2024 uses a burn up chart to track 150 story points across 8 sprints, adjusting scope when payment processor requirements change.
• A government digital service program running multi-year releases aggregates team contributions in a portfolio burn up chart for executive reporting.
• A startup tracking a 12-week MVP plots daily task completion against a fixed 80-item product backlog.

Burn up vs. burndown: key distinction

• A burndown chart shows work remaining, decreasing toward zero. When scope increases, the line jumps upward—making it look like the team suddenly has more to do without explaining why.
• A burn up chart makes scope changes explicitly visible because the scope line and progress line stay separate.

For a deeper dive into a complete guide to burndown charts, you can explore how they complement burn up charts in Agile tracking.

Prefer burnups when your scope evolves, your team does discovery-heavy work, or you’re managing long-running product roadmaps. A simple burndown may suffice for fixed-scope, short-lived projects like one sprint or a small feature.

How to create a burn up chart step by step

The process of creating a burn up chart works across spreadsheets (Excel, Google Sheets) and Agile tools like Jira, Azure DevOps, and ClickUp. These steps are tool-agnostic, so you can apply them anywhere.

Step-by-step process:

1. Define your scope: Establish the total work for your release or project. For example, your team estimates 120 story points for a billing system release.
2. Choose your metric: Decide whether you’ll track story points, issue counts, or hours. Story points work best for most scrum teams.
3. Set up the horizontal axis: Configure your x axis to show your time frame. For an 8-sprint release running April through July 2025, label each sprint or use calendar dates.
4. Configure the y axis: Scale it to accommodate your total scope plus potential growth. If starting at 120 points, set the y axis from 0 to 200 in increments of 20.
5. Add the scope line: Plot your initial scope as a horizontal line. This line may move upward if requirements expand.
6. Track completed work: At the end of each day or sprint, record cumulative completed work. Week 1 might show 15 points done, week 2 shows 30, week 4 shows 90.
7. Update regularly: Connect the data points to form your progress line. Update after each daily stand-up or at sprint boundaries.

Example with actual numbers: Your team begins a release with 120 story points planned. By sprint 3, new regulatory requirements add 30 points, pushing total scope to 150. Your burn up chart shows the scope line jumping from 120 to 150 at the sprint 3 boundary. Meanwhile, your completed work line has reached 45 points. The visual immediately shows stakeholders why the remaining work increased—without making your team look slow.

Configuring a burn up report in Agile tools:

1. Select your project or board from the main navigation.
2. Navigate to Reports and choose “Burn up” from available report types.
3. Set the date range (e.g., April 1 to July 31, 2025).
4. Select your estimation statistic—typically “Story points” or “Issue count.”
5. Save and share with your team; if you prefer spreadsheets, you can also create a burndown chart in Excel using similar underlying data.

Visual design tips:

• Use a red line or dark color for total scope—it represents the ceiling.
• Use a green line for completed work—it represents positive progress.
• Label both lines clearly in a legend.
• Avoid adding more than three lines total; keep charts simple and readable.

Your team should be able to set up a basic burn up chart in under an hour, whether using a spreadsheet template or a built-in tool report.

How to read and interpret a burn up chart

Reading a burn up chart means understanding what each line, gap, and slope tells you about delivery risk, progress velocity, and scope changes. Once you know the patterns, the chart becomes a powerful forecasting tool.

Understanding the axes:

• Horizontal axis (x axis): Shows time—typically sprint 1 through sprint 10, or calendar weeks/days.
• Vertical axis (y axis): Shows work units—commonly 0 to 200 story points in increments of 20.

Interpreting the gap: The space between the scope line and the completed work line at any date represents work remaining. For example:

• Total scope at sprint 4 end: 140 story points.
• Completed work at sprint 4 end: 90 story points.
• Work remaining: 50 story points.

If your team maintains velocity at 25 points per sprint, you can project completion in two more sprints, assuming you understand how to use Scrum velocity as a planning metric rather than a rigid performance target.

Common patterns and their meanings:

• Scope line rising mid-project: Indicates scope creep—new requirements added after planning. Common when regulatory or compliance needs emerge unexpectedly.
• Flat completed line for one sprint or more: Signals a blocked team. Investigate impediments immediately.
• Steep progress line (faster than expected): Could indicate overperformance, but also possible underestimation in planning.
• Scope line dropping: Shows de-scoping—features removed to hit a deadline. This is a deliberate trade-off decision.

Walkthrough example: Consider a 10-week web redesign project with 150 story points in scope. By week 3, the team has completed only 20 points—well below the ideal pace line that projected 45. The burn up chart makes this gap obvious. After the team removes a critical impediment (switching a blocked vendor integration), velocity doubles. By week 8, completed work reaches 140 points, nearly catching the scope line.

When patterns indicate risk—like a widening gap heading into a November 2025 release—the chart supports practical decisions: renegotiating scope with stakeholders, adding resources, or adjusting the delivery date.

Burn up vs. burndown charts

Both burnup charts and burndown charts track progress over time, but they show it from opposite perspectives. A burn up chart displays completed work rising toward scope. A burndown chart displays work remaining falling toward zero.

Key differences:

Concrete example:

• A 6-sprint API integration project starts with 100 story points. In sprint 2, the team discovers they need an additional authentication layer, adding 30 points (30% increase).
• On a burn up chart: The scope line jumps from 100 to 130 at sprint 2. The progress line continues climbing steadily at 20 points per sprint. Stakeholders see the scope change clearly.
• On a burndown chart: The remaining work line suddenly increases from 80 to 110 points. It looks like the team lost ground, even though they completed their planned work.

When to choose each chart:

• Product teams in 2024-2025 should prefer burnups when working on discovery-heavy products, multi-sprint releases, or any project where requirements evolve.
• Burndowns work better for fixed-scope, time-boxed work like a single sprint with a locked backlog or a maintenance release with predefined tasks.

Some teams use both charts side by side in Jira or Azure DevOps. This can provide comprehensive views, but teams should agree on which chart serves as the “single source of truth” for status reports and stakeholder communication, while using iteration burndown charts for sprint-level insight.

Advanced uses: release forecasting and portfolio views

Burn up charts work at the sprint level, but their real power emerges when applied to releases and multi-team portfolios spanning several quarters.

Release forecasting with projection lines:

• Overlay an “ideal” or projected progress line to forecast completion dates. Calculate your team’s average throughput from historical data—say, 20 story points per sprint over the last 6 sprints. Draw a line from your current position projecting forward at that rate.
• For example, if your release has 200 total story points with 80 completed by end of Q3 2025, and your team averages 20 points per sprint, you project completion around Q1 2026 (6 sprints remaining for 120 points).

Portfolio burn up charts:

• Leadership often needs visibility across multiple teams contributing to a single product launch. Jira dashboards and similar tools can surface this information through configurable Jira dashboards. A portfolio burn up aggregates work from separate teams:
  • Frontend team: 80 story points
  • Backend team: 120 story points
  • Mobile team: 60 story points
  • Combined portfolio scope: 260 story points
• The combined chart shows total scope and cumulative progress across all these factors, helping executives make resource allocation decisions.

Caveats for forecasting:

• Velocity variability: Holidays, sick days, and conference attendance can drop throughput 20-30%.
• Production incidents: Unplanned work steals capacity from planned features.
• Major scope changes: New compliance rules introduced mid-year can reshape the entire roadmap.
• Team composition changes: New team members ramp up slowly; departures create knowledge gaps.

Advanced setups might integrate burn up charts with other metrics like cycle time, work-in-progress limits, or defect rates, or combine them with additional engineering progress tracking tools such as Kanban boards and dashboards. However, keep the chart itself simple and readable—additional complexity belongs in separate reports.

While burn up charts are invaluable in Agile project management, the term “burnup” also plays a critical role in nuclear engineering, which we’ll explore next.

‍

Frequently asked questions about burn ups

Agile burn up chart questions

How often should we update our burn up chart—daily or per sprint?

Update frequency depends on your workflow. For sprints, updating at the end of each day during stand-ups provides early warning of issues. For releases spanning multiple sprints, updating at sprint boundaries often suffices. Kanban teams typically update daily since they don’t have sprint boundaries.

Can we use a burn up chart for Kanban instead of Scrum?

Absolutely. In Kanban, configure the horizontal axis as calendar days rather than discrete sprints. Plot cumulative completed work daily against your target scope. The cumulative flow diagram offers complementary insights, but a burn up chart still works for visualizing progress toward a goal.

What if our scope line keeps rising every sprint?

Persistent scope growth signals either poor initial estimation, stakeholder pressure, or unclear project boundaries. Use the burn up chart as evidence in stakeholder conversations. Show how each scope increase pushes out the projected completion date, then negotiate trade-offs: add resources, extend timelines, or cut lower-priority features.

Should we track at sprint level or release level?

Track at both levels if possible. Sprint-level burn up charts help the team during daily stand-ups. Release-level charts inform product managers and stakeholders about overall trajectory. Most Agile tools support both views from the same underlying data.

What’s a good indicator that we’ll hit our delivery date?

If your completed work line is tracking parallel to or above an ideal pace line connecting your start point to the target end date, you’re on track. If the gap between your progress line and scope line is shrinking at your current velocity, you should meet the deadline.

Key takeaways

For Agile teams:

• A burn up chart makes scope changes visible while tracking completed work.
• Use burn up charts when scope evolves; prefer burndowns for fixed-scope work.
• Update regularly and use the gap between lines to forecast your delivery date.

Start by creating a burn up chart for your next sprint. Watch how making scope and progress visible transforms your team’s conversations—and your ability to deliver on time.