Burn up Chart: A Clearer Way to Track Agile Project Progress /

Burn up Chart: A Clearer Way to Track Agile Project Progress

DATE Sep 2, 2025

READING TIME

4 min

AUTHOR Laith Adel

Tracking progress in Agile projects can be tricky, especially when scope changes mid-sprint or stakeholders want visibility into whether the team is on track. While burn down charts are common, many teams are turning to a more informative tool: the burn up chart.

This simple yet powerful visual shows not just how much work has been done, but also how much remains, and how scope is changing along the way.

In this blog, we’ll explain what a burn up chart is, how it works, and why it might be the best choice for transparent, dynamic project reporting.

What is a burn up chart?

A burn up chart is a visual representation of project progress over time. It helps teams track two important dimensions:

Work completed (usually in story points, tasks, or hours)
Total project scope (which may change during delivery)

By plotting both metrics on the same chart, you get a clear view of how much has been delivered versus how much is left, and whether the team is on track to meet the goal.

Burn up chart vs burn down chart

Burn up and burn down charts may look similar at first glance, but they communicate progress in very different ways. Here is a side-by-side comparison:

Feature	Burn Down Chart	Burn Up Chart
Tracks Work	Remaining work only	Both completed work and total scope
Scope Changes	Difficult to represent	Clearly visible
Interpretation	Less intuitive when changes occur	Easier to explain and understand
Preferred For	Fixed-scope sprints	Projects where scope may evolve

Bottom line: Burn up charts are more transparent when scope isn’t static.

How to read a burn up chart

A burn up chart might look simple, but it has several core components that make it effective:

X-axis: Time (e.g. sprint dates or calendar days)
Y-axis: Total effort (e.g. story points)
Scope line: A horizontal or adjusted line showing total effort expected
Progress line: Shows how much work has been completed over time

When the progress line meets the scope line, the work is done.

Example use case

Your product team is building a mobile app with an estimated effort of 100 story points. You visualise the work using a burn up chart:

Week 1: 15 points completed

Week 2: 30 points completed

Week 3: Scope increased to 120 points

Week 4: 90 points completed

The chart shows that progress is strong, but scope has increased. This gives stakeholders better insight into delivery reality than a burn down chart, which would only show remaining effort and could appear misleading.

Tools that support burn up charts

Several tools make it easy to create and manage burn up charts. Common options include:

Jira (with plugins like Easy Agile or Advanced Roadmaps)
Azure DevOps
Excel / Google Sheets (for custom charts)
Smartsheet
Power BI
pmo365 (for integrated portfolio-level burn up tracking)

These tools often provide automation, reporting, and portfolio-wide visibility, making it easier to keep charts accurate and up to date.

Benefits of using burn up charts

Teams adopt burn up charts because they offer benefits beyond traditional progress tracking. Some of the most important include:

Transparency: Clearly shows the impact of scope changes
Motivation: Teams can see how much they’ve already achieved
Stakeholder confidence: A clear, easy-to-explain visualisation
Adaptability: Works well in fixed and evolving projects
Better forecasting: Trends help estimate completion dates more reliably

Best practices for burn up charts

Burn up charts are only as effective as the way they’re used. To get the most value, keep these best practices in mind:

Update frequently
Ideally daily or at least every sprint to keep the chart meaningful.
Show scope changes clearly
Use distinct colours or annotations when scope increases or decreases.
Use real effort metrics
Story points, hours, or item counts should be consistent across sprints.
Align with stakeholders
Review the chart regularly with sponsors and product owners.
Combine with other charts
Use alongside velocity charts or cumulative flow diagrams for deeper insights.

Common pitfalls to avoid

Teams often fall into traps when setting up or maintaining burn up charts. Here are common mistakes and how to avoid them:

Pitfall	Impact	Fix
Not updating the chart regularly	Misleading data	Automate updates or schedule check-ins
Misrepresenting scope changes	Undermines trust	Keep a clear record of scope line adjustments
Using inconsistent metrics	Makes trends unreliable	Standardise estimation methods
No stakeholder engagement	Reduces value of insights	Include chart in sprint reviews or retrospectives

Conclusion: visualise progress the smart way

Burn up charts offer a more holistic, transparent, and adaptive way to track Agile project progress. Especially when scope is likely to shift, they provide a clear path to understanding what’s really happening, helping your team stay on track and your stakeholders stay in the loop.

For Agile teams that value both delivery and clarity, the burn up chart is an essential tool.

IIR: Introduce, Integrate, Replace

Introduce Integrate Replace

Step 01

Introduce

You cannot run a portfolio on Excel and PowerPoint alone.

Project portfolio management is the discipline of seeing every project in one place, prioritising the work that matters, allocating people against demand, and governing delivery with real numbers. It is not optional at any serious scale. The moment you have more projects than one person can hold in their head, you need a single, current view of status, schedule, cost, resource and risk.

Excel and PowerPoint feel free because there is no licence conversation. The real cost is elsewhere. It is the hours spent maintaining workbooks, the version confusion, and the numbers that go stale the moment they are pasted.

A spreadsheet cannot tell you, on demand, which projects are at risk, where your people are over-committed next quarter, or how much of the portfolio budget is actually spent.

Introducing a proper PPM platform is the first step. Not to add another tool for its own sake, but to give the portfolio one place where the data lives together and stays live.

Step 02

Integrate

The instinct after buying a PPM platform is to make everyone move into it. That is the fastest way to fail. Project managers already have tools they trust, and finance already has systems of record. Force a migration on day one and you get resistance, shadow spreadsheets, and a dataset nobody believes.

Integrate first. Meet the data where it already is. Two directions matter.

Direction 01

Enterprise systems

Connect to the finance or ERP layer so actuals, commitments and budgets flow in automatically. Reporting stops being a monthly reconciliation and becomes a live view. Nobody rekeys a spend figure again.

Direction 02

The tools PMs already use

The direction most platforms neglect, and arguably the more important. The portfolio should read from the PM's own tools, not force people to abandon them.

The reason this matters is simple. That data is already there, and it is kept current by the person closest to it. When the portfolio reads directly from these sources, the status report updates itself. No chasing, no copy and paste, no reporting lag. The PM keeps working the way they always have, and the board gets a live picture as a side effect.

Step 03

Replace

Integration buys you two things: trust, and live data. Once both are in place, you look at what can go.

Every organisation carries tools and spreadsheets that either do not do the job well or carry a heavy maintenance overhead. The classic example is the resource spreadsheet. It is a workbook someone maintains by hand to track who is on what. It is always slightly out of date, owned by one person, and impossible to reconcile against real demand.

Replace it with the equivalent function in your PPM.

A proper demand management capability does what the spreadsheet was reaching for, with none of the overhead. It models demand against capacity across the whole portfolio, updates as projects shift, and needs no manual upkeep.

Replace deliberately, one function at a time, and only after the platform has earned it. The test is simple: if a spreadsheet is high overhead or low quality, and the platform does the same job natively, retire the spreadsheet.

The payoff

You stop producing reports and start reading them

Follow IIR and the nature of reporting changes. The status view is current because it is fed by the tools people already use and the systems that already hold the money. The overhead that used to consume the last week of every month disappears, because there is nothing to assemble.

That is the whole point of real-time reporting. Not a prettier deck, but a portfolio you can look at any day of the month and trust, at a fraction of the effort it takes today.

Built on Microsoft 365. Native ground for IIR.

pmo365 integrates with the tools your teams already run in, so the path from Introduce to Integrate to Replace is a natural progression rather than a rip and replace.