Agile Estimation Techniques for the PMP Exam: Story Points, Planning Poker, T-Shirt Sizing & More

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

Estimation is one of those topics that feels like it belongs in the predictive world — earned value, parametric models, bottom-up WBS estimation. But the PMP exam tests estimation extensively in agile and hybrid contexts too, and the techniques are fundamentally different. You won't be asked to calculate PERT estimates for user stories, but you will be expected to know when to use story points versus ideal days, how planning poker works, and what velocity tells you about a team's capacity.

This guide covers every agile estimation technique the PMP exam tests, explains when to use each one, and shows you how to recognize estimation questions in both agile and hybrid scenarios.

Why Agile Estimation Is Different (And Why the PMP Exam Cares)

Predictive estimation asks: "How long will this take?" Agile estimation asks: "How big is this relative to other things we've done?" The shift from absolute to relative estimation is the conceptual foundation of every agile technique on the exam. Rather than committing to precise hour-based estimates months before the work begins — an approach that PMI acknowledges is unreliable in complex, evolving environments — agile teams estimate using comparative sizing and then derive forecasts from empirical data (velocity).

The PMP exam tests this distinction because it goes to the heart of the agile mindset. Questions that reward absolute, upfront, hour-based estimates in agile contexts are almost always wrong. Questions that reward relative sizing, team-based estimation, and empirical forecasting are almost always right.

Key Exam Principle: Estimation Is a Team Activity

In predictive project management, the project manager or a specialist estimator produces the estimates. In agile, the people doing the work estimate the work. This isn't a preference — it's a principle. The PMP exam will penalize answers where the project manager unilaterally estimates story points or overrides the team's sizing. Estimation is collective, comparative, and iterative.

Story Points: The Core Agile Estimation Unit

Story points are the most fundamental agile estimation concept on the PMP exam. A story point is a relative measure of effort, complexity, and uncertainty — not a measure of time. A 5-point story isn't "5 hours of work"; it's "roughly five times as big as a 1-point story."

Story points combine three dimensions:

• Effort: How much work is involved? This is the primary dimension but not the only one.
• Complexity: How technically difficult or cognitively demanding is the work? A simple CRUD endpoint might be low-effort but high-complexity if it integrates with a legacy system.
• Uncertainty (Risk): How much is unknown? A story with clear acceptance criteria and known technology might be a 3, while a similar-sized story with vague requirements and an unfamiliar API might be an 8 — because uncertainty increases the likely effort.

Common story point scales include the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) and powers of two (1, 2, 4, 8, 16). The gaps between numbers increase as the size increases, reflecting the reality that larger estimates carry more uncertainty. The PMP exam may reference these scales but won't ask you to calculate specific point values — it tests why the scales are structured this way.

Planning Poker: How Teams Arrive at Story Points

Planning poker (also called scrum poker) is the most commonly referenced collaborative estimation technique on the PMP exam. The process is designed to eliminate anchoring bias — the tendency for the first number spoken to influence everyone else's estimate.

The Planning Poker Process:

1. The product owner presents a user story and answers clarifying questions from the team.
2. Each team member privately selects a card representing their estimate (using story points, typically Fibonacci scale).
3. All cards are revealed simultaneously — this is the mechanism that prevents anchoring.
4. If estimates are consistent (within one card value of each other), the team converges on the average or the most common value.
5. If estimates diverge significantly (one person holds a 3 while another holds a 13), the outliers explain their reasoning. Discussion focuses on different assumptions about complexity, effort, or risk.
6. The team re-estimates after discussion. The process repeats until convergence.

Exam scenarios involving planning poker: The PMP exam will present a planning poker session gone wrong and ask what the project manager should do. Common scenarios include:

• The team is rushing through estimation without discussion. Correct answer: remind the team that the value of planning poker is in the conversation, not the number. The discussion that reveals hidden complexity is more valuable than the estimate itself.
• One team member is dominating the conversation and anchoring others. Correct answer: reinforce the simultaneous-reveal rule and ensure everyone estimates independently before discussion.
• The product owner is pressuring the team for lower estimates. Correct answer: the servant leader protects the team; the product owner can clarify scope but cannot dictate estimates. Estimation belongs to the delivery team.
• Estimates are consistently taking too long to converge. Correct answer: consider switching to a simplified technique like T-shirt sizing for initial backlog grooming, then follow up with planning poker for sprint-ready stories.

T-Shirt Sizing: Rough-Cut Estimation for Large Backlogs

T-shirt sizing (XS, S, M, L, XL, XXL) is a high-level relative estimation technique used for initial backlog grooming, portfolio planning, and early-stage project scoping. It trades precision for speed — you can T-shirt-size 200 backlog items in an hour, whereas planning poker might take a full day for the same backlog.

When the exam favors T-shirt sizing:

• The backlog is large (100+ items) and hasn't been refined yet
• The project is in early initiation; detailed story-level estimates would be premature
• The goal is to provide the sponsor with an order-of-magnitude forecast, not a sprint-level commitment
• The team is new and doesn't yet have a velocity baseline — precise story points would provide false precision

T-shirt sizing process: Items are categorized into size buckets relative to a reference story — typically a well-understood, medium-sized story that serves as the anchor. "If the login story is a Medium, where does the reporting dashboard story fall?" Teams physically or digitally sort items into columns labeled XS through XXL. Once sized, T-shirt sizes can be mapped to story point ranges (XS = 1, S = 2–3, M = 5, L = 8–13, XL = 20–40).

Affinity Estimation: Grouping for Speed and Consistency

Affinity estimation (also called "silent grouping" or "relative mass estimation") is a technique for sizing large backlogs quickly by grouping similar-sized items together. It's faster than planning poker and more structured than T-shirt sizing, making it ideal for mid-project backlog refinement when the team has velocity data but the backlog has grown.

The process:

1. Write each backlog item on a card (physical or digital).
2. The team places cards on a wall or board, arranged left (smallest) to right (largest), using existing story-point-scaled reference cards as benchmarks.
3. Team members place cards silently — discussion happens after all cards are placed. This preserves the speed advantage while still benefiting from the "wisdom of the crowd" effect.
4. After initial placement, the team reviews outliers and discusses them — similar to the planning poker discussion phase.
5. Final point values are assigned based on cluster positions.

Exam relevance: The PMP exam may present affinity estimation as the correct answer when the scenario describes a large, growing backlog and a team that needs to estimate quickly without sacrificing relative accuracy. The key signal is "the team has velocity data and can reference previously estimated stories" — affinity estimation leverages historical reference points that T-shirt sizing lacks.

Velocity: From Estimates to Forecasts

Velocity is not an estimation technique — it's the empirical bridge between story point estimates and delivery forecasts. Velocity is calculated by summing the story points completed in a sprint (or iteration). After three to five sprints, the team's average velocity becomes a reliable predictor of future capacity.

How the PMP exam tests velocity:

• Calculating how many sprints remain. "A team has 120 story points remaining in the backlog and an average velocity of 25 points per sprint. How many sprints will it take?" The answer is 5 sprints (120 / 25 = 4.8, round up to 5). Simple math, but watch for the rounding — always round up because partial sprints don't exist.
• Velocity as a team-specific metric. "Team A has a velocity of 30; can Team B use that number?" The answer is no — velocity is team-specific and context-dependent. Comparing velocity across teams is meaningless because story point sizing is relative to each team's reference stories.
• Velocity fluctuations. "A team's velocity dropped from 30 to 18. What should the project manager do?" The exam does NOT want you to assign blame or push for higher velocity. The correct answer is to investigate the cause — was there a team member absence? A particularly complex story? An external impediment? Use velocity as a diagnostic tool, not a performance metric.
• Using velocity for release planning. The product owner uses velocity to forecast which features will be delivered by a target date. This is a projection, not a commitment — the exam rewards treating velocity forecasts as probabilistic rather than deterministic.

When to Use Each Technique: The PMP Decision Tree

The exam tests not just what each technique is, but when to apply it. Here's the decision framework:

Scenario	Recommended Technique	Why
Early project, 200+ unrefined backlog items, need high-level forecast for sponsor	T-shirt sizing	Speed over precision; detailed estimation premature
Sprint-ready stories, need team commitment on sprint capacity	Planning poker	Precise, collaborative, reveals hidden complexity through discussion
Mid-project, backlog ballooned to 150 items, team has velocity history	Affinity estimation	Faster than planning poker, leverages existing reference stories
Team new to agile, unfamiliar with abstract story points	Ideal days (as transition step)	Easier for teams coming from predictive; migrate to story points over time
Need 12-month roadmap forecast for portfolio planning	T-shirt sizing → map to point ranges → apply velocity	Two-stage: rough sizing for backlog, velocity for timeline
Hybrid project: predictive track needs cost estimate, agile track needs sprint capacity	Predictive: parametric/bottom-up. Agile: planning poker	Different estimation for different workstreams; don't force one approach

Estimation in Hybrid Projects

Hybrid estimation is one of the more nuanced topics on the PMP exam. When a project blends predictive and agile workstreams, the project manager must respect each track's estimation approach while producing an integrated forecast for stakeholders who expect traditional metrics (cost, schedule, scope).

Key hybrid estimation principles for the exam:

• Don't force story points onto predictive work. The construction phase of a hybrid project uses bottom-up or parametric estimation. Don't ask the structural engineering team to use planning poker for concrete pour estimates.
• Don't force hour-based estimates onto agile teams. If the agile development team estimates in story points, don't demand that they convert to hours for the integrated schedule. Instead, use velocity to forecast completion dates and map those to the master schedule.
• Create an integrated forecast at the milestone level. The predictive track provides date-certain milestones; the agile track provides velocity-based completion ranges. The integrated plan shows both, with confidence intervals around the agile portions.
• Communicate the difference to stakeholders. The PMP exam expects you to educate sponsors that agile forecasts are probabilistic, not deterministic — and that this is a feature of the approach, not a failure of estimation.

Common Estimation Pitfalls on the PMP Exam

Here are the traps the exam sets repeatedly — and how to avoid them:

• Pitfall: The sponsor asks "how many hours is 8 story points?" Correct answer: explain that story points measure relative size, not time, and that the team's velocity provides a more reliable forecast than hour-based conversion. Do NOT convert story points to hours.
• Pitfall: The team's velocity has been stable for 8 sprints, then drops by 40%. Correct answer: investigate the cause. Don't assume the team is underperforming. Possible causes include technical debt accumulation, a new team member joining, or a particularly complex feature set.
• Pitfall: The product owner wants to add 20 story points to a sprint because "we're behind schedule." Correct answer: the team owns sprint capacity. The product owner can reprioritize the backlog (swap stories of equal size) but cannot unilaterally increase the sprint commitment. Velocity is observed, not dictated.
• Pitfall: The team is consistently overestimating (velocity keeps exceeding the sprint plan). Correct answer: this isn't necessarily a problem. The team may be improving, or the reference stories may need recalibration. Celebrate the delivery and adjust future forecasts — don't penalize the team for beating estimates.

Bringing It All Together

Agile estimation on the PMP exam is about mindset more than math. You won't need to memorize the Fibonacci sequence, but you do need to internalize these principles: estimates are relative, not absolute; estimation is a team activity, not a manager's decree; velocity is for forecasting, not performance evaluation; and different project phases deserve different estimation techniques. When you encounter an estimation question, filter every answer through these principles. The correct answer will almost always be the one that respects team autonomy, embraces relative sizing, and treats forecasts as empirical rather than contractual.