"The board wants a date." The delivery lead has four sprints of history — 18, 22, 20, and 20 points — and 160 points left in the release backlog. What she says next separates a pass from a trap, because agile estimation questions on the PMP exam are almost never about the arithmetic. They're about what story points and velocity are for, and just as much about what they're not for.
Why relative estimation exists
Story points express the size of a backlog item relative to other items — a bundle of effort, complexity, and uncertainty, not hours in disguise. The exam expects you to know why teams estimate this way: people compare far more reliably than they measure in absolute units, relative sizing is fast enough to estimate a whole backlog, and it refuses the false precision of promising hours for knowledge work no one has done yet.
The techniques stems mention by name: planning poker (simultaneous reveal, then discussion — the conversation that surfaces hidden assumptions is the point, not the number), affinity grouping and t-shirt sizing (bulk-sizing large backlogs quickly). If a question asks why estimates from planning poker beat one expert's estimate, the answer is the exposed assumptions and shared understanding, not mathematical accuracy.
One rule carries several questions on its own: story points are a team-local currency. Each team's scale emerges from its own history. There is no exchange rate between teams, and converting points to hours for reporting quietly destroys the model.
75 free questions, scored against the new domain weights. No card required.
Velocity: an empirical forecast, not a speedometer
Velocity is simply the points a team completes per sprint, averaged over recent history. Its legitimate use is forecasting: 160 points remaining at an average velocity of 20 suggests around eight sprints. Two habits mark the exam-correct forecaster. First, ranges beat points: recent velocity spanned 18 to 22, so the honest answer is roughly seven to nine sprints. Second, re-forecast every sprint — velocity is self-correcting as evidence accumulates, which is precisely its advantage over a plan made once and defended forever.
Scenario 1. A release backlog holds 160 story points. The team's last four sprints produced 18, 22, 20, and 20 points. The sponsor asks the project manager when the release will be done. What is the best response?
- A. Commit to exactly eight sprints, since 160 divided by 20 is 8
- B. Share a forecast of roughly seven to nine sprints based on observed velocity, and update it with the sponsor after every sprint
- C. Convert the remaining points into hours to produce a precise delivery date
- D. Ask the team to increase velocity to 25 points so the release lands within the quarter
Answer: B. Empirical data, expressed as a range, refreshed as reality arrives — that's the whole agile forecasting posture in one option. A launders variance into false certainty. C abandons relative estimation exactly where it's most useful. D treats a measurement as a dial you can turn, which leads directly to the failure mode below.
How management breaks velocity — and what the exam wants you to do
The moment velocity becomes a target or a scoreboard, it stops measuring anything. Teams compared against other teams inflate their point scales — same work, bigger numbers. Teams ordered to "hit 25" cut quality or pad estimates. The exam builds scenarios around exactly this misuse, and the correct response is nearly always the same shape: coach the stakeholder. Explain that velocity is team-specific planning data, then offer measures that legitimately serve their need — delivered outcomes, business value, cycle time trends.
Scenario 2. A PMO director publishes a dashboard ranking five agile teams by velocity and directs the lowest-ranked team to match the top team within two quarters. What should that team's project manager do?
- A. Build a conversion table to normalize story points across the five teams
- B. Explain to the director that velocity is team-relative planning data, and propose outcome-based measures for cross-team reporting
- C. Have the team re-estimate its backlog with a more generous point scale
- D. Accept the target and track the team's velocity against it each sprint
Answer: B. The servant-leader move is to protect the measurement system and meet the director's real need — comparable reporting — with metrics that can bear the weight. A pretends an exchange rate exists. C is open point inflation. D converts a planning instrument into a quota and guarantees the numbers stop meaning anything.
The estimation questions behind the questions
Notice that neither scenario turns on computation. When numbers appear in agile estimation stems they divide cleanly, and the division is step one of four — the scored judgment is what you say with the result. That's typical of how the 2026 exam mixes light math into scenario items; our question types guide shows the formats this arrives in. Estimation also consistently punishes half-prepared candidates — see where it lands in our hardest topics analysis. And when a stem describes flow-based work with no sprints at all, forecasting shifts from velocity to throughput and cycle time — covered in our Kanban and flow metrics guide.
Reps make the difference: ExamElephant's bank drills these exact judgment patterns, and its retest engine returns every missed question at 3 and 7 days until you've mastered it. The first 75 questions are free.
Paid passes are coming soon
The full 2,100-question bank, timed 180-question mock exams and unlimited tutoring. Leave your email and we'll tell you the day they open. Unsubscribe anytime. Privacy
FAQ
Do I need to know the Fibonacci sequence for the exam?
Recognize it as a common point scale — the widening gaps deliberately reflect growing uncertainty in bigger items. You won't be quizzed on the sequence itself.
Can story points ever be converted to hours?
Teams sometimes glance at hours when splitting sprint tasks, but any option that converts points to hours for commitments or cross-team reporting is a distractor. It reintroduces the false precision points exist to avoid.
What replaces velocity on a Kanban team?
Throughput (items finished per period) and cycle time. Forecasts come from flow data instead of sprint history — same empirical philosophy, different clock.
Is a higher velocity better?
Only a stable velocity is better — it makes forecasts trustworthy. A rising number often just means inflation, which is why "raise velocity" options are almost always wrong.