Planning poker, T-shirt sizing, and three-point estimation as three different tools for three different situations, and why relative story-point sizing tends to be more consistent than raw hour guesses.
Published September 23, 2026
Each team member privately picks an estimate (a card: 1, 2, 3, 5, 8, 13...)
-> everyone reveals simultaneously -> if estimates diverge widely, the highest
and lowest estimators explain their reasoning -> re-estimate, repeat until converged
The SIMULTANEOUS reveal is the entire point — estimating out loud one at a time means the first person's number anchors everyone after them (a well-documented cognitive bias), collapsing the group toward one person's guess rather than surfacing genuinely different perspectives. Planning poker's brief discussion round after a wide-divergence reveal is often more valuable than the number itself — a 3-point estimate and a 13-point estimate for the same story usually means one person sees a complexity the other missed, and THAT conversation is what improves the team's shared understanding of the work.
S / M / L / XL — no numbers, no false precision, just relative bucketing
T-shirt sizing deliberately avoids numeric precision — it's for EARLY-STAGE triage (roadmap planning, quarterly prioritization) where the real question is "is this a day of work or a month of work," not a precise point estimate. Forcing precise story-point estimates on a barely-scoped epic produces FALSE confidence (a specific-looking number for something genuinely too vague to estimate accurately yet) — T-shirt sizing is honest about that uncertainty instead of hiding it behind a number.
Estimate = (Optimistic + 4 × Most-Likely + Pessimistic) / 6 (PERT-style weighting)
A single-point estimate hides genuine uncertainty — three-point estimation makes the RANGE explicit (what if everything goes right, what if it doesn't, what's realistically most likely), then combines them into one weighted figure that accounts for the fact that things going WRONG is usually more likely and more impactful than things going unusually right. This is most valuable for genuinely uncertain work (a task touching unfamiliar code, or depending on an external team) where a single confident-looking number would be misleading.
Raw-hour estimates tend to be systematically optimistic (everyone underestimates interruptions, meetings, unexpected complexity) and don't transfer well between people (my "4 hours" and yours might mean different things given different familiarity with the code). RELATIVE sizing (story points, comparing a new story's complexity against previously-estimated ones: "this feels about as complex as that 5-pointer we did last sprint") tends to be more CONSISTENT over time — it doesn't require predicting exact duration, just relative complexity, which people are demonstrably better at judging than absolute time.
Q: How would you choose between these three techniques for a specific planning session? A: T-shirt sizing for early, still-vague roadmap items; planning poker for well-defined sprint-ready stories where the team's shared understanding matters as much as the number; three-point estimation for individually complex, high-uncertainty tasks where a single number would hide real risk — matching the technique to how well-understood the work actually is, not defaulting to one method for everything.
Q: Does converting story points back to a calendar date ever make sense? A: Yes, via observed VELOCITY (how many points the team actually completes per sprint, on average, over several past sprints) rather than assuming a fixed points-to-hours conversion — this is exactly the historical-velocity approach referenced in Capacity Planning, avoiding the false precision of a theoretical hours-per-point conversion that ignores real team throughput.
Q: What if planning poker consistently fails to converge for a specific team? A: Persistent wide divergence across many stories is itself a useful signal — it often means the team lacks genuinely shared context on the codebase or requirements (worth addressing directly, perhaps via more pairing or documentation), not just a symptom of the estimation technique itself being flawed.
Q: Is there a risk in estimation becoming a purely mechanical, box-checking exercise? A: Yes — if the DISCUSSION that estimation techniques are meant to surface (differing assumptions, hidden complexity) gets skipped in favor of just quickly picking a number to move on, the technique loses most of its actual value; the number itself matters less than the shared understanding the estimation CONVERSATION is supposed to produce.