September 8, 2026 · 8 min read
TL;DR: These two charts are keyed 9 times and used as distractors 8 times in this bank, so neither is the safe default. Two questions settle nearly every item. What is the horizon, iteration or release? And is the scope moving? A burndown shows remaining work over one timebox and folds any scope change invisibly into its single line. A burn-up separates completed work from total scope, so a scope change shows up as the scope line moving. When a stem mentions changing scope or asks for both done and remaining, the burn-up is doing work the burndown cannot.
Candidates tend to learn these as interchangeable pictures of the same thing. They are not. One of them can hide the single most important fact in the scenario, and the bank builds items directly on that difference.
Whether total scope has its own line.
The bank states this in an explanation about an executive team that, following a directive to improve operational efficiency, asks for an update on progress and remaining work across all ongoing agile projects. Keyed is the sprint burn-up chart, and the reasoning names both halves of the question. The executives asked for what has been completed and what remains. A burn-up plots both as separate lines, cumulative work completed rising from the bottom, total scope drawn as its own line above it, so the gap between them is the remaining work and any movement in the scope line is visible rather than hidden.
Then comes the sentence that makes this a rule rather than a description. That last property matters here, because efficiency directives tend to change what is in scope.
That is the discriminator. A burndown has one line. If someone adds twenty points of scope while the team completes twenty points of work, a burndown is flat and looks like a team that achieved nothing. A burn-up shows a team that delivered twenty points into a target that moved.
The one whose horizon matches the question being asked.
| Scenario in the bank | Keyed artifact | Why the neighbour fails |
|---|---|---|
| Executives want progress and remaining work under an efficiency directive | Sprint burn-up chart | Scope is likely moving; a burndown hides that in one line |
| Sponsor wants a big-picture view of implemented versus outstanding | Cumulative flow diagram and feature burn-up | Iteration burndown's horizon is one timebox, not the release |
| Sponsor anxious the project will not finish on time | Velocity plus the product burndown | A chart alone gives a quantity but no rate to forecast with |
| Sponsor thinks the team achieved little in two weeks | Team burndown chart against what was committed | The question is about one iteration, so the iteration view fits |
| Stakeholder wants to know how the team is really progressing | Burndown from the information radiator, plus velocity | Engagement and comms plans describe process, not progress |
| Sprint planning: which two inputs are needed? | Sprint goal and product backlog | The burndown reports what already happened |
The second row is the one worth studying. A sponsor asks for a big-picture view of what has been implemented versus what is still outstanding, and the options include an iteration burndown chart, a feature burn-up chart, a cumulative flow diagram and a Kanban board. Two are keyed: the cumulative flow diagram and the feature burn-up. The iteration burndown is not.
The bank's explanation says why in one phrase. The sponsor is asking a release-level question, so the two artifacts that answer it are the ones whose horizon is the whole release. The iteration burndown is not a worse chart. It is a chart pointed at the wrong horizon.
For a forecast, no.
A sponsor is anxious midway through an agile project that it may not finish on time. Keyed is reviewing the team's velocity, the product burndown chart and other KPIs. The explanation frames the sponsor's question as a forecast question, will this finish on time, and says answering it needs a rate and a remaining quantity, which is exactly what velocity and the product burndown supply between them.
It then adds a detail worth carrying into any agile metrics question. Velocity averaged over several completed iterations gives the team's demonstrated throughput rather than its hopes. The burndown gives the remaining scope and the slope at which it has actually been coming down. One without the other is either a speed with no distance or a distance with no speed.
Compare that with the sponsor who thinks the team has not got enough done over the past two weeks. There, keyed is reviewing the team burndown chart to see the flow of work against what was committed, on its own. The difference is that this is not a forecast at all. It is a claim about one iteration that already happened, and the iteration burndown is the team's own record of it. The explanation puts it well: an impression is best answered with the team's own record of it rather than with a reaction.
Common trap: treating the burndown as the default agile progress chart and reaching for it whenever a stem says progress. This bank names it as the near miss in at least three separate records, and the reason is different each time. In the release-level question it is the wrong horizon. In the sprint planning question it reports the past when the meeting needs the future. In the communications question it appears inside an option that is wrong for a different reason entirely: occasional centralised communication using burndown charts shown at demonstrations, where the defect is the centralised, occasional delivery, not the chart. Reading the whole option rather than recognising the chart name is the skill being tested, and the bank flags these distractors by name in its explanations.
Three more artifacts show up alongside these two and each answers a distinct question.
The cumulative flow diagram stacks the amount of work in each state over time. The bank's explanation notes that a single picture then shows total scope, how much is complete, how much is in progress and how much is still waiting, and that the widening or narrowing of the bands carries information too. That makes it a release-horizon artifact, which is why it pairs with the feature burn-up rather than with an iteration burndown.
Velocity is a rate, not a picture of remaining work. The Kanban board shows current state, not trend, which is why it loses to the cumulative flow diagram on a big-picture question. And the information radiator is the delivery mechanism rather than a chart at all: the bank keys sharing the burndown from the team's information radiator, and separately keys the radiator itself over centrally controlled reporting when the question is about how information reaches a wide stakeholder group.
One more useful oddity. In a record about building slack into a sprint, one distractor is producing a burndown chart and a burn-up chart together. Keyed is adding a refactoring card that can be dropped if an emergency arrives. Charts measure capacity; they do not create it.
What is the difference between a burndown chart and a burn-up chart on the PMP exam? A burndown plots work remaining falling toward zero. A burn-up plots cumulative work completed rising from the bottom with total scope drawn as its own separate line above it. The practical consequence is that a burn-up makes a scope change visible as a movement in the scope line, while a burndown absorbs it into the same single trace and hides it.
When should you choose a burn-up chart over a burndown? When the question asks for both what has been done and what remains, or when scope is likely to be moving. The bank keys a sprint burn-up for an executive asking for progress and remaining work under an efficiency directive, specifically because efficiency directives tend to change what is in scope and the burn-up shows that rather than hiding it.
Is a burndown chart the right answer for a sponsor worried about the finish date? Partly. The bank keys reviewing velocity together with the product burndown, not the burndown alone. A forecast question needs a rate and a remaining quantity, so velocity supplies the demonstrated throughput and the product burndown supplies how much of the release scope is left.
Why is a burndown chart a distractor in sprint planning questions? Because it reports progress already made rather than what to do next. The bank keys the sprint goal and the prioritised product backlog as the two inputs sprint planning needs, and names the burndown from the previous sprint as the near miss for exactly that reason.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 Exam Content Outline, and every wrong answer is explained, not just marked wrong, so you learn why the neighbouring chart lost rather than only that it did. Start the free 20-question sample — no card, no signup required to try it.
What is the difference between a burndown chart and a burn-up chart on the PMP exam?
A burndown plots work remaining falling toward zero. A burn-up plots cumulative work completed rising from the bottom with total scope drawn as its own separate line above it. The practical consequence is that a burn-up makes a scope change visible as a movement in the scope line, while a burndown absorbs it into the same single trace and hides it.
When should you choose a burn-up chart over a burndown?
When the question asks for both what has been done and what remains, or when scope is likely to be moving. The bank keys a sprint burn-up for an executive asking for progress and remaining work under an efficiency directive, specifically because efficiency directives tend to change what is in scope and the burn-up shows that rather than hiding it.
Is a burndown chart the right answer for a sponsor worried about the finish date?
Partly. The bank keys reviewing velocity together with the product burndown, not the burndown alone. A forecast question needs a rate and a remaining quantity, so velocity supplies the demonstrated throughput and the product burndown supplies how much of the release scope is left.
Why is a burndown chart a distractor in sprint planning questions?
Because it reports progress already made rather than what to do next. The bank keys the sprint goal and the prioritised product backlog as the two inputs sprint planning needs, and names the burndown from the previous sprint as the near miss for exactly that reason.