September 6, 2026 · 8 min read
TL;DR: Agile measurement shows up in 84 questions in this bank, and velocity is both the most-offered measure and one of the least reliably correct: keyed 12 times against 20 appearances as a distractor. Burn-up charts run the other way, keyed 5 times against 1. The exam is testing whether you know what each measure is a measure of, whose team it belongs to, and whether the scenario is running iterations or flow.
A Kanban team wants to know how much work it can finish in the next three months. One option multiplies velocity by the number of remaining user stories. It is arithmetic, it produces a number, and it is wrong twice over, because this team does not run iterations and because velocity was never a rate you multiply by a story count. The keyed answer projects the team's recent throughput forward. That question is the whole topic in miniature.
Because it is a genuine measure that candidates apply outside the two conditions that make it meaningful: one team, and iterations to measure it over. Break either condition and velocity becomes the distractor.
The clearest case is a newly formed team planning its first iteration with no history of its own. A team member suggests using the 38-point average velocity of an established team elsewhere in the organization. The options let you take that number, split the difference between it and what the product owner wants, have the scrum master set a number from the backlog size, or take on a conservative number now and use the team's own actual completion rate for subsequent iterations.
The keyed answer is the conservative start, and the explanation is worth memorizing because it generalizes: story points are a team-relative estimate, not an absolute unit. The same-sized story can be a 3 for one team and an 8 for another, depending on how each has calibrated its own scale. Borrowing another team's velocity imports a number that is not measured in this team's units at all.
Common trap: treating velocity as a performance target rather than an observation. Options that push a team to raise its velocity, or decompose stories in order to boost it, are distractors every time they appear in this bank. Velocity is an output you read to forecast with. The moment it becomes a goal, the team can raise it by re-estimating the same work upward, which changes the number and nothing else. One question offers "decompose the user stories to boost velocity" against "discuss the velocity issue with the product owner" and keys the conversation, because the release cannot fit and somebody has to choose what to trade.
Read the stem for whether the team runs iterations or flow, then for whether the question is about capacity, progress, duration or scope.
| Measure | What it measures | Keyed | Distractor | Belongs to |
|---|---|---|---|---|
| Velocity | Story points completed per iteration | 12 | 20 | One Scrum team, its own history only |
| Throughput | Work items finished per period | 2 | 3 | Flow-based boards |
| Cycle time | How long one item takes start to done | 3 | 1 | Flow-based boards |
| Burn-up chart | Completed work and total scope as separate lines | 5 | 1 | Either, when scope may move |
| Burndown chart | Remaining work descending to zero | 4 | 8 | Either, within a fixed scope |
| Cumulative flow | Where work piles up between stages | 1 | 0 | Flow-based boards |
The burn-up and burndown numbers are the most useful pair here, because they are the same idea measured differently and the bank keys them very differently. A burndown shows remaining work going down, which is easy to read and hides one thing: if scope is added, the line flattens and looks identical to a team slowing down. A burn-up plots completed work and total scope as two lines, so added scope lifts the scope line visibly. When a question mentions changing scope and offers both, the burn-up is usually the answer.
For flow-based teams, throughput and cycle time are the pair. Throughput answers how much gets done in a period, cycle time answers how long one item takes. One question asks which measure to use to understand how long user stories are taking, and cycle time is keyed. Another asks how to forecast three months of a Kanban team's work, and throughput projected forward is keyed against multiplying velocity by story count and against multiplying lead time by the schedule performance index. That last distractor is a nice one: it mixes a flow measure with an earned value index, producing something with no meaning at all.
Whatever it does not measure, which sounds obvious until the exam offers a plausible-looking measure for a question about people rather than work.
One question asks for a measure that shows team morale slipping before it shows up in delivery. The options are the velocity recorded for the current iteration, the work performance report for the period, the to-complete performance index, and the rate of unplanned turnover on the team. Turnover is keyed, and the explanation is precise about the other three: velocity moves for many reasons that have nothing to do with how the team feels, a work performance report describes the work rather than the people doing it, and the to-complete performance index is a cost measure entirely.
This is the discipline the topic is really testing. Every one of those distractors is a real measure, correctly named, that a project manager might legitimately track. What makes them wrong is that none of them measures the thing the stem asked about, and the bank's explanations name that mismatch rather than just marking the option wrong.
Can I compare one team's velocity with another team's? No. Story points are team-relative, so the same story can be a 3 for one team and an 8 for another. A new team starts conservatively and uses its own actual completion rate from then on.
What is the difference between velocity and throughput? Velocity is story points per iteration, a Scrum measure. Throughput is work items finished per period, a flow measure that pairs with cycle time. A Kanban team has no iterations to measure velocity over.
Should I use a burndown or a burn-up chart? Burn-ups are keyed 5 times against 1 here, burndowns 4 against 8. A burn-up shows completed work and total scope separately, so added scope is visible rather than looking like slow progress.
What do I do when velocity says the release date will be missed? Take it to the product owner. Every real option trades business value, and that trade is theirs to make.
The agile questions in this bank are certified against PMBOK 8 and the July 2026 exam content outline, and each explanation names what the offered measure actually measures and why it does not fit the scenario, every wrong answer explained rather than just marked wrong. Start the free 20-question sample with no card and no signup.
Related reading: Evaluating Project Status: Read the Variance Before You Report It and Choosing a Delivery Approach. The domain breakdown is on the Process study page.
Sources: PMI, Project Management Professional (PMP) Exam Content Outline
Can I compare one team's velocity with another team's?
No, and the exam tests this directly. Story points are a team-relative estimate rather than an absolute unit, so the same story can be a 3 for one team and an 8 for another depending on how each calibrated its scale. In one question a new team with no history is offered an established team's 38-point average velocity as a planning basis; the keyed answer takes on a conservative number for the first iteration and uses the team's own actual completion rate from then on.
What is the difference between velocity and throughput?
Velocity is a Scrum measure, the story points a team completes per iteration. Throughput is a flow measure, the number of work items finished in a period, and it pairs with cycle time, how long one item takes from start to done. The distinction matters because a Kanban team running a flow-based board has no iterations to measure velocity over. One question in this bank puts exactly that team on the page and keys projecting recent throughput forward.
Should I use a burndown or a burn-up chart?
Burn-up charts are keyed 5 times in this bank against 1 appearance as a distractor, the strongest ratio of any agile measure here, and burndowns are keyed 4 times against 8. The practical difference is that a burn-up plots completed work and total scope as separate lines, so scope being added is visible on the chart, whereas a burndown collapses both into one descending line where added scope just looks like slow progress.
What do I do when velocity says the release date will be missed?
Take it to whoever owns the trade-off. In one question velocity drops after two sprints and the five-sprint release forecast no longer holds. Reprioritizing the backlog, adding team members and decomposing stories to boost velocity are all offered; the keyed answer discusses the velocity issue with the product owner, because every real option trades business value and that decision is the product owner's rather than the project manager's.