When PMI announced the updated PMP exam, one line in its own write-up is worth more study time than most candidates give it. The exam now includes "case/scenario and graphic-based questions, along with more practical content built around dashboards, project artifacts, tools, and data." That is a different skill from recalling a definition. It asks you to look at a picture of a project and say what is actually happening.
Combine that with the delivery mix published in exam summaries — roughly 40% predictive and roughly 60% agile and hybrid — and a specific gap opens up. Many candidates can define velocity. Fewer can look at a chart, say which of four conclusions the chart supports, and reject the three that it does not.
This guide covers the four charts most likely to show up in an adaptive or hybrid scenario, what each one does and does not tell you, and the decision each should lead to.
Why charts carry more weight now
The structural changes behind this are already public. The domain weights moved to People 33%, Process 41%, and Business Environment 26% — the last of those up from 8% on the previous exam. PMI describes the refreshed exam as shifting "focus to outcomes, value and business impact." Published summaries put the exam at 180 questions in 240 minutes.
Outcomes and value are hard to test with a terminology question. They are easy to test with a chart, because a chart forces you to separate two things: what the data says, and what you should do about it. Those are different answers, and the exam often offers both.
Burndown: remaining work against time
A burndown chart plots work left to do on the vertical axis against time on the horizontal axis. It carries two lines. The ideal work remaining line is a straight diagonal from the starting scope to the target end date — a mathematical assumption that the team completes work at a constant rate. The actual work remaining line is the real data, plotted each day in a sprint or each sprint in a release.
The reading rule is simple: actual line above the ideal line means more work remains than planned, and actual below ideal means less. Remaining work is measured in either time estimates or story points.
The limitation matters more than the rule, and the exam knows it. A burndown chart depends entirely on estimate accuracy. A team that habitually overestimates will sit comfortably below the ideal line while doing ordinary work; a team that underestimates will look behind no matter how much it delivers. A burndown line is a statement about the relationship between estimates and completion, not a measurement of effort.
There is a second blind spot. If the team completes five points and the product owner adds five points in the same period, the burndown is flat. Flat looks like a stalled team. It is not necessarily a stalled team.
Burnup: the same progress, plus the scope line
A burnup chart plots completed work upward from zero, and adds a second line for total scope. That second line is the whole point of the chart.
In the flat-burndown case above, a burnup chart is unambiguous. The completed-work line keeps climbing at its usual rate, and the scope line steps up at the same moment. You can see at a glance that the team's throughput was unchanged and the backlog grew. Published comparisons of the two charts make this the burnup chart's primary advantage: scope change is visible rather than hidden inside a single ambiguous line.
So when a question shows a flat or worsening burndown and asks what to do first, "investigate whether scope changed" is usually a stronger move than "address team performance." And when a question asks which artifact would make a recurring argument about scope creep easier to settle, the burnup chart is the answer the chart's design actually supports.
Velocity: a planning input, not a performance score
Velocity is the rate at which a team creates, validates, and approves deliverables within a defined interval — in practice, the points a team completes per sprint. If a team expects to finish about ten points a sprint, its velocity is ten.
Two traps follow from that definition, and both appear regularly in scenario questions.
The first is treating velocity as a target. Velocity is an observation used to forecast how much backlog a team can plausibly take into the next iteration. Setting it as a goal invites estimate inflation, which makes the number useless for the one job it has.
The second is comparing velocity across teams. Story points are calibrated inside a team, against that team's own reference work. Ten points for one team and ten for another are not the same quantity of anything. A question in which a sponsor or manager wants two teams ranked by velocity is testing whether you will say so.
The correct use is narrow: a team's own velocity trend, over several iterations, as an input to release forecasting and to conversations about capacity.
Cumulative flow: where the work is piling up
A cumulative flow diagram is a stacked area chart — time on the horizontal axis, cumulative item count on the vertical axis, with one band per workflow state. It describes a Kanban-style or flow-based system rather than a sprint, which makes it the chart most likely to appear in a hybrid scenario.
Four readings are worth memorizing.
| What you see | What it means |
|---|---|
| Thickness of the In Progress band | Current work in progress |
| Slope of the Done band | Throughput — steeper is faster |
| In Progress band widening | WIP accumulating; a bottleneck downstream |
| To Do band widening | Incoming work arriving faster than it is delivered |
A flattening Done band means throughput has dropped, whatever the other bands are doing. The horizontal gap between a band and the Done line approximates how long items are taking to get through.
The decision these push toward is usually a flow decision rather than a staffing one: limit work in progress, find and clear the constrained step, or address intake. A scenario showing a steadily widening In Progress band and offering "add more people to the team" as an option is offering you the wrong lever — adding intake to a system that is already backed up makes the band wider.
A reading routine for chart questions
Under time pressure, work in a fixed order.
- Read the axes before the lines. Remaining work and completed work slope in opposite directions, and mixing them up inverts your whole answer.
- Identify the delivery approach the chart implies. A burndown or velocity reference implies iterations. A cumulative flow diagram implies a flow-based system, and the correct response changes with it.
- Say in one sentence what the data shows, without a recommendation attached.
- Only then pick the action. Separate "the trend is worsening" from "therefore escalate," because the exam will often offer a correct observation attached to a premature action.
- Check the options against the chart's known blind spots. If a burndown is involved and scope change is on the table, that is usually the thread to pull.
What not to over-study
You do not need to calculate anything from these charts. There is no burndown formula to memorize and no standard points-to-hours conversion, because there is no valid one. What you need is the ability to name what a shape means and to choose a response consistent with the delivery approach in the scenario.
The highest-value practice is not reading more about the charts. It is working through scenario questions where a chart or a dashboard description is the stem, and forcing yourself to write the one-sentence observation before you look at the options.
Practice questions to try next
Work through agile and hybrid scenario sets and pay attention to any question that describes a trend rather than an event. Those are the chart questions in disguise, and they reward the same reading routine.