CAPM Relative Sizing and Planning Poker

Study CAPM Relative Sizing and Planning Poker: key concepts, common traps, and exam decision cues.

Relative sizing helps adaptive teams compare backlog items without pretending they can predict exact hours too early. Planning poker and similar techniques improve that comparison by surfacing hidden assumptions before the team commits to a size.

Why Adaptive Estimation Works Differently

Adaptive teams often estimate at a planning level rather than at a task-hour level. The goal is not to avoid discipline. The goal is to use an estimation method that fits iterative planning and ongoing refinement.

Relative sizing helps the team compare effort, complexity, and uncertainty across items. It becomes especially useful when exact durations would create false precision.

CAPM questions often turn on this distinction. A predictive environment may need detailed task durations earlier because it is building a long-range sequence with dependencies, baselines, and control thresholds. An adaptive team usually needs a different first question: which backlog items appear larger, riskier, or less understood than others? Relative sizing answers that comparison question without claiming the team already knows every implementation detail.

That is why story points, T-shirt sizes, and similar methods are not weak substitutes for “real estimating.” They are fit-for-purpose planning tools. They support ordering, capacity planning, and conversation. The value is not the number by itself. The value is the shared understanding the number represents.

Why Consensus Discussion Matters

Planning poker is valuable because the team estimates independently first and then discusses differences. If one person sees a story as very small and another sees it as much larger, that gap usually reveals hidden assumptions or dependencies worth discussing.

The strongest CAPM answer usually values the discussion, not the cards themselves.

In practice, a wide gap in estimates often points to one of four issues:

What the gap may mean Why it matters for planning
The story is being interpreted differently The team is not estimating the same work
A dependency or constraint is hidden The size may grow once the dependency is addressed
The acceptance criteria are weak The team cannot judge completion reliably
The team has different technical assumptions Implementation effort and risk are still unclear

If a scenario shows the team jumping straight to an average, the strongest response is usually to pause and clarify. Averaging before discussion can make the estimate look precise while leaving the real planning problem untouched.

Visual Guide

This layout teaches the lesson faster than a simple flowchart because planning poker depends on relative scale and visible estimate gaps. The point is not the card ritual by itself. The point is that a wide spread in estimates exposes hidden assumptions that the team should discuss before locking in the size.

Relative sizing and planning poker comparison for CAPM

Notice what the diagram emphasizes: comparison, not conversion. CAPM is much more likely to reward “use the estimate spread to expose assumptions” than “convert the story points into person-hours.”

What Good Estimation Looks Like

Good adaptive estimation usually follows a repeatable sequence:

  1. Start with backlog items that are small enough to discuss meaningfully.
  2. Confirm the item’s objective and acceptance criteria.
  3. Estimate comparatively against work the team already understands.
  4. Discuss outliers and hidden assumptions.
  5. Re-estimate once the team shares the same mental model.

That flow keeps the estimate attached to planning usefulness. If the item is still too ambiguous after discussion, the best response is often not to argue harder about points. It is to refine, split, spike, or defer the item until it becomes estimation-ready.

What CAPM Is Really Testing

CAPM usually tests three applied distinctions here:

  • story points are relative planning units, not exact labor hours
  • estimation disagreement is a signal to investigate, not a nuisance to suppress
  • backlog readiness affects estimate quality

A common trap is to treat planning poker as a voting ceremony that automatically produces truth. It does not. It is a structured conversation aid. If the inputs are weak, the output stays weak. For example, if acceptance criteria are vague or the item mixes multiple outcomes, even a neat consensus number may still be misleading.

Example

A team compares two stories and sees that one appears roughly twice as complex and uncertain as the other. That comparison may be more useful than forcing exact hours immediately. If the team then disagrees sharply on the larger story, planning poker-style discussion can expose why.

Suppose one developer assumes an existing API can be reused, while another expects a new integration approval and security review. The estimate gap is not a personality difference. It is evidence that the team is still estimating two different versions of the work. The right next step is clarification, not simply picking the median card.

Exam Scenario

During refinement, a product owner asks the team to estimate a new story immediately because leadership wants faster forecasting. Several developers say the story is still broad and mixes multiple outcomes. One person suggests assigning a number now and “cleaning it up later” so the roadmap looks complete.

The strongest CAPM response is to improve the story enough for meaningful comparison or split it into smaller items. Relative sizing works best when the item is coherent. The exam usually rewards backlog readiness and shared understanding over cosmetic certainty.

Common Pitfalls

  • treating story points like exact hours
  • assuming the consensus number matters more than the assumptions behind it
  • averaging widely different estimates without discussion
  • using another team’s sizing scale as if it were a universal standard
  • estimating oversized backlog items that should first be split or refined
  • using leadership pressure as a reason to hide estimation uncertainty

Check Your Understanding

### Why do adaptive teams use relative sizing? - [ ] To calculate payroll exactly from story points - [ ] To eliminate the need for backlog refinement - [x] To compare backlog items for planning without forcing false precision too early - [ ] To guarantee exact delivery dates from the first estimate > **Explanation:** Relative sizing supports comparison and planning under uncertainty rather than premature precision. ### What is the strongest benefit of planning poker or similar techniques? - [ ] They guarantee the estimate is exact - [x] They surface different assumptions and improve shared understanding before finalizing the estimate - [ ] They remove the need for backlog clarification - [ ] They let one expert control every estimate alone > **Explanation:** The discussion around differing views is the main value of the technique. ### What is usually a weak interpretation of story points? - [ ] Using them to compare work relatively - [ ] Combining them with team planning discussion - [ ] Using them as part of iteration planning - [x] Treating them as exact durations > **Explanation:** Story points are usually relative planning units, not exact time commitments. ### A backlog item receives estimates of `2`, `3`, `8`, and `13`. What is the strongest next step? - [ ] Average the numbers immediately so the team can move on - [ ] Record the lowest estimate because optimistic planning creates urgency - [x] Ask why team members see the work differently before finalizing the estimate - [ ] Escalate the disagreement to the sponsor for a final estimate > **Explanation:** A wide spread usually reveals different assumptions, missing clarity, or hidden dependencies that need discussion.

Sample Exam Question

Scenario: During backlog refinement, one developer estimates a story at 3 points and another estimates it at 13. The facilitator pauses the session and asks the team to explain the gap before agreeing on a final size.

Question: Why is that the strongest next step?

  • A. Because the highest estimate should always win automatically
  • B. Because the estimate should be escalated to the sponsor instead of discussed
  • C. Because the difference likely reflects assumptions that matter for planning
  • D. Because consensus techniques are designed to eliminate discussion

Best answer: C

Explanation: CAPM usually rewards using estimation differences to expose hidden assumptions about complexity, uncertainty, or dependency before the team commits to a plan.

Why the other options are weaker:

  • A: Highest is not automatically correct.
  • B: This is normally a team-planning issue, not sponsor escalation.
  • D: The point of the technique is discussion, not silence.
Revised on Monday, April 27, 2026