Agile Metrics on the PMP Exam: Velocity, Burndown Charts, CFD, and More

Published: 2026-05-27 · By FreePMPTests Editorial Team

Agile metrics questions on the PMP exam are deceptively simple. They rarely ask you to calculate anything complex — there are no earned value formulas here. Instead, they test your ability to interpret what a chart or metric is telling you and respond appropriately. A burndown chart that's tracking above the ideal line. A velocity that suddenly drops. A cumulative flow diagram with a widening "in progress" band. What does each signal mean, and what should the project manager do about it?

This article gives you a complete, exam-ready guide to every agile metric PMI might test. We'll cover what each metric measures, what patterns signal trouble, and — most importantly — how to answer the scenario questions that follow.

Velocity: The Most Misunderstood Metric on the Exam

Velocity is the amount of work a team completes in a sprint, measured in story points (or sometimes ideal hours). It's a planning tool, not a performance target. This distinction is the single most important thing to understand about velocity for the PMP exam.

PMI's Agile Practice Guide is explicit: velocity should be used for forecasting, not for comparing teams or setting performance goals. Two teams with different velocities are not "better" or "worse" — they're sized differently, or they estimate differently, or they work in different domains. Comparing velocity between teams is one of the most common agile anti-patterns, and the PMP exam will punish answers that try to do it.

How the exam tests velocity:

• Forecasting questions: "A Scrum team has completed five sprints with the following velocities: 28, 31, 29, 30, 32. The product backlog contains 240 story points of remaining work. Approximately how many sprints remain?" The answer uses average velocity (~30) divided into remaining work (~240) to get ~8 sprints. Simple arithmetic, but the exam expects you to recognize this as a legitimate extrapolation.
• Velocity decline questions: "A team's velocity has dropped from 30 to 18 over the past three sprints. Team members say they feel fine. What should the Scrum Master do?" The correct answer involves investigating the root cause collaboratively — not scolding the team, not forcing them to "try harder," and not switching to hours-based estimation. Velocity drops can signal technical debt accumulating, stories growing larger, team members leaving, or interruptions from outside work. The response is always investigation, not punishment.
• Anti-pattern recognition: "A stakeholder asks the Scrum Master to set a velocity target of 40 story points for the next sprint. What should the Scrum Master do?" The correct answer: explain that velocity is an outcome of the team's capacity and the work's complexity, not a target to be mandated. Forcing velocity leads to inflated story points, skipped quality practices, and burnout.

Burndown and Burnup Charts: Reading the Story

Burndown and burnup charts are the most visual agile metrics, and they appear frequently on the PMP exam. You need to read them like a story — each pattern tells you something specific about what's happening on the project.

Sprint Burndown Chart

A sprint burndown shows remaining work (in story points or hours) on the Y-axis versus days of the sprint on the X-axis. The "ideal line" is a straight diagonal from the total work at Day 0 to zero at the last day. The actual line tracks the team's real progress.

Key patterns and their meanings:

• Actual line above ideal line (throughout the sprint): The team is behind plan. They may not finish the sprint commitment. This calls for the team to inspect and adapt — possibly by reducing scope in negotiation with the Product Owner, or by swarming on remaining work.
• Actual line below ideal line: The team is ahead of plan. They may finish early. In Scrum, this means pulling in additional backlog items (the Product Owner's decision) or using the remaining time for technical debt reduction, learning, or refinement.
• Flat period followed by cliff drop: No progress for several days, then a sudden large drop. Suggests the team isn't updating remaining work daily, or that large stories are being completed all at once. This is a process smell — the Scrum Master should encourage daily updates to burndown data so the chart actually reflects reality.
• Scope increase (the line goes UP): New work was added mid-sprint. This is a major sprint anti-pattern. In Scrum, the sprint backlog is supposed to be fixed once the sprint starts. If scope increases mid-sprint, the Scrum Master should protect the team and negotiate with the Product Owner to add new work to the next sprint instead.

Release Burndown Chart

A release burndown tracks remaining work across multiple sprints toward a release goal. It shows whether the team is on track to deliver the planned scope by the release date. Key patterns:

• Trend line intersecting above zero at the release date: The team will not complete all scope by the release date. The Product Owner has three options: descope (remove lower-priority items), extend the date, or accept that some work won't be done.
• Trend line dropping faster than the ideal line: The team is over-delivering relative to estimates. The Product Owner may choose to add scope or pull the release date forward.

Burnup Chart

A burnup chart shows completed work (rising) rather than remaining work (falling). It includes both a "total scope" line and a "completed work" line. The key advantage of a burnup over a burndown: it visually shows when scope has changed. If the total scope line moves upward, you can see exactly when and how much scope was added — something a burndown chart hides because scope increases just look like the team falling behind.

On the PMP exam, burnup chart questions typically test whether you notice the scope change. If a scenario describes a project where "the team seems to be falling behind" but the burnup chart shows total scope increased by 40%, the correct answer is to discuss scope management with the Product Owner, not to push the team to work faster.

Cumulative Flow Diagram (CFD): The Systems-Thinking Metric

The cumulative flow diagram is PMI's favorite agile metric for testing systems thinking. A CFD shows the number of work items in each workflow state (To Do, In Progress, Done, etc.) stacked over time. The width of each band at any point in time represents the number of items in that state.

Key CFD patterns for the PMP exam:

• Widening "In Progress" band: Work is arriving faster than it's being completed. This signals a bottleneck — likely too much work in progress (WIP). The correct response is to reduce WIP limits and help the team focus on finishing work rather than starting new work. PMI rewards this insight: stop starting, start finishing.
• Widening "To Do" band with stable "Done": The team is keeping up with current work but the backlog is growing. This suggests the team needs more capacity or the intake rate needs to be managed. The correct response involves a conversation with the Product Owner about prioritization.
• Narrowing "In Progress" band and rapidly growing "Done": The team is finishing work efficiently. This is the healthy pattern — work flows smoothly through the system without accumulating in any state.
• Stair-step pattern in "Done": Work is being completed in large batches at the end of sprints (or less frequently) rather than continuously. This suggests batch processing rather than continuous flow — common in Scrum but worth noting in Kanban contexts where continuous delivery is the goal.

CFD questions on the PMP exam typically present a pattern (like the widening in-progress band) and ask what it indicates. The correct answer always connects the pattern to a systemic issue (too much WIP, a bottleneck, uneven flow) and a systemic response (reduce WIP, address the bottleneck, balance capacity) — not a team-level fix like "tell the developers to work faster."

Lead Time and Cycle Time: The Flow Metrics

Lead time and cycle time are Kanban metrics that PMI increasingly tests on the PMP exam. They measure how quickly work moves through the system — and how long customers wait for value.

• Lead time: The total time from when a work item is requested to when it's delivered. Clock starts when the customer asks for something; clock stops when they receive it.
• Cycle time: The time from when the team starts working on an item to when it's delivered. Clock starts when work begins; clock stops when it's done. Cycle time is always a subset of lead time — the difference is the time the item spent waiting in the backlog before work began.

How the exam tests these:

• Lead time increasing while cycle time stays stable: Items are spending more time waiting in the backlog before work begins. This means the team has more work than capacity — the backlog is growing. The correct response is to address intake: limit WIP, prioritize more aggressively, or increase capacity.
• Cycle time increasing: Work is taking longer to complete once started. This could signal increasing complexity, technical debt, or excessive WIP causing context-switching. The correct response is to investigate root causes — not to blame the team.
• High variability in cycle time: Some items take 2 days, others take 20. This indicates inconsistent work item sizes or unpredictable blockers. The correct response is to break work into smaller, more consistent pieces and improve blocker identification.

PMI's Agile Practice Guide emphasizes that reducing lead time delivers value faster and improves customer satisfaction. The exam rewards answers that focus on flow efficiency — getting work through the system faster — rather than resource efficiency — keeping everyone 100% busy. A team at 85% utilization with smooth flow outperforms a team at 100% utilization with constant context-switching, and PMI knows it.

Throughput: The Output Metric

Throughput is the number of work items completed in a given time period (e.g., 8 user stories per week). It's the Kanban counterpart to velocity, but it's measured in count of items rather than story points. Throughput is particularly useful when work items are of relatively consistent size, or when you're tracking at a level of granularity where item count is meaningful (e.g., features per month).

On the PMP exam, throughput questions are often about forecasting: "Over the last 8 weeks, the team has completed 4, 5, 3, 5, 4, 6, 5, 4 features per week. There are 23 features remaining. When can the customer expect delivery?" Using an average throughput of ~4.5 features per week, delivery is approximately 5 weeks away. But the exam also expects you to acknowledge variability — giving a range (4–6 weeks) rather than a single date, because throughput naturally fluctuates.

Escaped Defects: The Quality Metric

Escaped defects are defects discovered after a work item has been marked "Done" — by users, in production, or by a downstream team. They're a direct measure of the team's Definition of Done and quality practices. A rising escaped defect count signals that the Definition of Done isn't thorough enough, testing is insufficient, or the team is rushing to meet sprint commitments at the expense of quality.

PMI treats escaped defects as a leading indicator of quality problems and expects the exam candidate to connect them to process issues. The correct response to rising escaped defects is never "fix the bugs faster" — it's "strengthen the Definition of Done to prevent them from escaping in the first place." This might mean adding code review, automated testing, pair programming, or a more rigorous acceptance criteria review to the team's quality practices.

How to Interpret Metrics in Exam Scenarios: A Decision Framework

When you encounter an agile metrics question on the PMP exam, walk through this mental checklist:

1. Identify the metric: What is being measured — velocity, burndown, CFD, lead time, cycle time, throughput, escaped defects? Each metric tells a different story.
2. Identify the pattern: What is the trend — rising, falling, stable, variable? Is there a specific anomaly (sudden drop, scope increase, widening band)?
3. Diagnose the systemic cause: Don't jump to a team-level fix. Ask what process or system condition would produce this pattern. Too much WIP? Inflated estimates? Insufficient testing? Growing backlog?
4. Select the collaborative response: The correct answer will almost always involve the team inspecting and adapting together — not a manager imposing a solution. "Discuss with the team," "inspect the process," "review the Definition of Done together" — these are PMI's preferred framings.
5. Eliminate the command-and-control answers: "Instruct the team to work faster," "set a higher velocity target," "penalize the underperforming team." Any answer that treats metrics as a performance stick rather than a planning tool is wrong.

Agile Metrics vs Predictive Metrics: A Quick Comparison

Aspect	Agile Metrics	Predictive Metrics (EVM)
Purpose	Enable team self-management and continuous improvement	Enable management oversight and variance control
Primary measures	Velocity, burndown, lead/cycle time, throughput, CFD	SPI, CPI, SV, CV, EAC, ETC, TCPI
Granularity	Sprint-level; daily updates; team-owned	Project-level; periodic reporting; PM-owned
Response to variance	Team inspects and adapts; adjusts backlog or process	PM analyzes variance; initiates change requests
Forecasting method	Empirical: extrapolate from actual team performance	Formula-based: calculate EAC from CPI/SPI combinations
Exam weight	Medium (scenario interpretation, not calculation)	Medium (formula memorization + scenario interpretation)

Remember: the PMP exam doesn't pit agile metrics against EVM. In hybrid projects, both can coexist — the Scrum team uses velocity and burndown charts internally, while the PMO receives EVM reports for governance. The exam tests whether you understand when to use each, not which one is "better."

Master agile metrics by internalizing their purpose: they exist to help the team see its own process, identify improvement opportunities, and make better forecasts — not to judge, rank, or pressure. When you approach every metrics question through that lens, the correct answer becomes clear.