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.
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.
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.
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.
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.”
Good adaptive estimation usually follows a repeatable sequence:
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.
CAPM usually tests three applied distinctions here:
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.
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.
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.
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?
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: