Walk into any agile team's standup and you'll see one of these two charts on the wall. Walk into a different team's standup and you'll see the other. Ask either team why they picked the one they did, and the answer is usually "that's what Jira gave us."
That's a problem. Because a burndown chart and a burn-up chart look almost identical, they get treated as interchangeable. They aren't. They answer different questions, hide different things, and lie about your project in different ways.
If you're prepping for the PMP, the exam will absolutely test whether you can tell them apart. If you're running a real project, picking the wrong one will quietly mislead your stakeholders for months.
Here's everything that actually matters.
The 30-Second Version
A burndown chart shows work remaining over time. The line starts at the top-left and slopes down toward zero. When the line hits zero, the work is done.
A burn-up chart shows work completed over time, plotted against a separate line representing the total scope. The completed-work line climbs up. The scope line sits above it. When the two lines meet, the work is done.
Same data, different framing. The reason this matters: the burn-up chart shows scope changes; the burndown chart hides them.
That single distinction is why most experienced agile coaches prefer burn-up charts, and why the PMP exam tends to favor burn-up questions when the scenario involves stakeholder communication.
What a Burndown Chart Actually Shows
A burndown chart plots work remaining (Y-axis) against time (X-axis). It's typically used at two scopes:
- Sprint burndown — tracks story points or hours remaining during a single sprint
- Release burndown — tracks story points remaining across a release made up of multiple sprints
The chart usually includes two lines:
- The ideal line — a straight diagonal from total work at the start to zero at the end. This is the "if we burn down work at a perfectly constant rate" reference.
- The actual line — a jagged line showing what really happened day by day or sprint by sprint.
If the actual line is above the ideal line, you're behind. If it's below, you're ahead.
What the burndown chart is good at
- Quick gut check. At a glance, are we on track for this sprint?
- Daily standup focus. Sprint burndowns make it obvious when the team is falling behind early enough to course-correct.
- Velocity smoothing visualization. You can see whether the team picks up pace mid-sprint or burns down evenly.
What the burndown chart hides
This is where it gets dangerous.
If your product owner adds 10 new story points to the sprint on day 3, a strict burndown chart has two options: either it ignores the new scope (and the chart becomes a lie), or it adds the new work to the remaining line (which makes the team look like they're falling behind, even though they're delivering at the same pace).
Both options are bad. Both hide important information from stakeholders. A sponsor looking at a burndown that suddenly jumps up has no idea whether the team is failing or whether new work was added. A sponsor looking at a burndown that smoothly decreases doesn't know that scope was secretly trimmed to make the chart look good.
This is the single most common reason mature agile teams switch to burn-up charts.
What a Burn-Up Chart Actually Shows
A burn-up chart plots two lines on the same chart:
- Total scope line — the sum of all work in the release or sprint, drawn as a horizontal (or stepped) line at the top.
- Completed work line — the cumulative amount of work finished, climbing from zero upward.
The work is done when the completed line touches the scope line.
What the burn-up chart is good at
- Honest about scope changes. If scope is added, the top line jumps up. If scope is cut, the top line drops down. Everyone looking at the chart can see the change, when it happened, and how big it was.
- Better for executive conversations. A stakeholder can see at a glance: "We're delivering steadily, but the scope keeps growing. That's why the release date keeps moving."
- Trend forecasting. Project the completed-work line forward, project the scope line forward, and see where they intersect. That's your forecast delivery date — without the scope distortion a burndown chart introduces.
- Multi-team rollups. Burn-ups stack cleanly when you're aggregating across several teams.
What the burn-up chart hides
Burn-up charts make sprint-level "are we on track today" decisions slightly harder because the eye has to compare two lines instead of judging one line's slope. For a single short sprint, a burndown is faster to read at a glance.
That's basically the only real tradeoff.
The Side-by-Side That Makes It Click
Imagine a 10-sprint release. The team commits to 200 story points. After sprint 3, the product owner adds 60 points of new must-haves. The team's actual velocity is steady at 25 points/sprint.
Burndown chart view:
| Sprint | Remaining (no scope change) | Remaining (with scope add) |
|---|---|---|
| 0 | 200 | 200 |
| 1 | 175 | 175 |
| 2 | 150 | 150 |
| 3 | 125 | 185 (jumps up) |
| 4 | 100 | 160 |
| ... | ... | ... |
| 10 | -50 (ahead) | 10 (behind) |
The burndown line jumps mid-release. To a stakeholder who wasn't in the planning meeting, it looks like the team blew up. The team has to constantly re-explain that scope was added — and even then, the chart fights the narrative.
Burn-up chart view:
| Sprint | Completed | Total Scope |
|---|---|---|
| 0 | 0 | 200 |
| 1 | 25 | 200 |
| 2 | 50 | 200 |
| 3 | 75 | 260 (scope line jumps up) |
| 4 | 100 | 260 |
| ... | ... | ... |
| 10 | 250 | 260 |
The completed line climbs smoothly. The scope line stair-steps up exactly when work was added. Anyone looking at the chart immediately sees: "The team is delivering at the same pace they always have. Scope grew. That's why we're not finishing on the original date."
Same project. Same outcome. Wildly different story for stakeholders.
What the PMP Exam Actually Tests
The PMP exam doesn't typically ask you to draw either chart. It tests whether you understand which chart fits which situation. The most common question patterns:
Pattern 1: Stakeholder communication scenario A scope-creep scenario where the team needs to show stakeholders why a deadline is slipping. The correct answer is almost always burn-up, because the scope line makes the cause visible.
Pattern 2: Daily standup / sprint visibility The team needs a quick visual to track sprint progress at standup. Either chart can work, but burndown is the textbook answer for sprint-level tracking.
Pattern 3: Release forecasting The team needs to predict when a release will actually finish given current velocity. Burn-up is preferred because you can project both the completed-work trend and the scope trend independently.
Pattern 4: "What is this chart showing?" You're given a description and asked to name the chart type. The key tells:
- Two lines, one climbing, one mostly flat at top → burn-up
- One line sloping down toward zero → burndown
- Discontinuity that looks like a step → that's a scope change on a burn-up
A specific trap to watch for: if a question describes a chart where scope is being adjusted, and asks which chart the team should use to show progress honestly to stakeholders, the answer is burn-up. If the question describes the same scenario and asks which chart is standard for sprint tracking, the answer can still be burndown.
The PMP exam loves these "both are technically correct but one is best for this situation" framings. Read the question carefully — what's the audience? What's the time horizon? What does the chart need to communicate?
When to Pick Which (Real-World Version)
Forget the exam for a moment. If you're picking a chart for an actual team, here's how to decide.
Use a burndown when:
- You're running a single sprint and scope is locked
- The audience is the team itself, not stakeholders
- You want a fast, low-friction daily visual
- Your tool defaults to burndown and you're not going to fight it
Use a burn-up when:
- Stakeholders are involved
- Scope changes are expected (which, in reality, is most projects)
- You need to forecast delivery dates that include scope volatility
- You're aggregating across multiple teams
- You want one chart that tells the whole story without a verbal explanation
If you can only have one chart on the wall for a multi-sprint release, make it a burn-up.
Common Mistakes Teams (and PMP Candidates) Make
Mistake 1: Treating the ideal line as a target. The ideal line on a burndown is a reference, not a goal. Real teams don't burn down evenly. They burn down in chunks as stories complete. A burndown that hugs the ideal line is suspicious — it usually means someone is updating points to make the chart look right, not because work is actually getting done.
Mistake 2: Hiding scope changes by re-baselining. Some teams "reset" their burndown when scope changes, restarting from a new total. This destroys the value of the chart entirely. Don't do it. Either show the scope change honestly on a burn-up, or accept the burndown jump and explain it.
Mistake 3: Confusing release burndown with sprint burndown. The mechanics are the same. The time scale is different. The PMP exam will sometimes hand you a release-level scenario and use sprint-burndown language to throw you off. Look at the X-axis units in the question.
Mistake 4: Reading too much into one data point. A single sprint that finishes below the ideal line doesn't mean the team is failing. A single sprint above doesn't mean they're ahead. Trends over 3+ sprints are the signal. Single sprints are noise.
Mistake 5: Ignoring the team's actual velocity in favor of the chart. The chart is a representation of velocity, not the source of it. If velocity is stable at 25 points/sprint, the chart is going to be honest. If velocity is wildly inconsistent, no chart will save you.
Where These Charts Came From
Burndown charts were popularized by Ken Schwaber in early Scrum literature in the late 1990s. They were elegant for the constraint they were designed for: a fixed sprint backlog over a short time window, where scope changes were forbidden by the framework.
The trouble started when teams began applying burndowns to releases, programs, and portfolios — places where scope absolutely does change. Burn-up charts emerged as the pragmatic fix, often credited to Mike Cohn and other early agile-at-scale practitioners.
Today, both Jira and Azure DevOps generate both charts by default. Most teams default to whichever is more visually prominent in their tool. Most teams also never decide; they just use what's there.
That's your competitive advantage on the exam and in real work: actually understanding which one to pick.
Quick Reference Table
| Question | Burndown | Burn-Up |
|---|---|---|
| Shows work remaining? | Yes | No (shows work done) |
| Shows scope changes? | Hides or distorts them | Shows clearly |
| Best for daily standup? | Yes | Acceptable |
| Best for stakeholder updates? | No | Yes |
| Best for forecasting delivery? | Limited | Strong |
| Best for multi-team rollup? | Awkward | Clean |
| PMP exam default for sprint tracking? | Burndown | — |
| PMP exam default when scope is changing? | — | Burn-up |
The Bottom Line
If you remember nothing else: a burndown chart hides scope changes. A burn-up chart shows them.
Everything else flows from that one fact. Choose burndown when you want a fast visual for a fixed sprint. Choose burn-up when honesty about scope matters — which on real projects, and on most PMP exam questions, is most of the time.
Want to test whether you can spot which chart fits which scenario? Practice agile questions from the 2026 PMP ECO — they're all free, no signup needed.
Related reading: Burndown Chart concept page · Burn-Up Chart concept page · Sprint Review · Velocity