Agile estimation techniques compared
Agile estimation techniques compared — planning poker, T-shirt sizing, buckets, dot voting, affinity and magic estimation, and the failure mode each one hides.
Planning poker is one estimation technique among several, and it isn’t always the right one. Every technique is a trade — speed for precision, coverage for depth, a number for a conversation. The technique you pick is really the failure mode you’ve decided you can live with.
The techniques at a glance
| Technique | Best for | Output | Time per item |
|---|---|---|---|
| Planning poker | 5–20 well-refined stories | Story points (numeric) | 2–5 min |
| T-shirt sizing | Early refinement, roadmap work | XS–XL (categorical) | 30–60 sec |
| Bucket system | Sizing 50+ items quickly | Story points (numeric) | 10–20 sec |
| Affinity mapping | Sizing a fresh backlog from scratch | Relative groupings → points | 5–15 sec |
| Magic estimation | Long, well-understood backlogs | Story points (numeric) | 10–20 sec |
| Dot voting | Prioritisation, not estimation | Vote counts | ~10 sec |
Planning poker
The right call when you have a focused backlog and need shared understanding, not just a number. The private-vote-then-reveal mechanic catches the disagreement other techniques smooth over.
Fails when the stories aren’t ready. Planning poker is the slowest of the lot, and unrefined stories turn that slowness into a refinement meeting badly disguised as estimation. If the cards spread from 3 to 13, you don’t have an estimation problem — you have an unsplit story.
T-shirt sizing
XS, S, M, L, XL. Faster than planning poker because you’ve dropped the granularity. Common in early refinement, in product and leadership conversations, and on teams that have deliberately moved away from numeric sizing.
Fails when someone outside the team needs a velocity number. T-shirts don’t add up, and the moment you build a conversion table on the wiki to make them add up, you’ve reinvented story points with extra steps.
Bucket system
The team drops items into pre-labelled buckets (1, 2, 3, 5, 8…) with a fast pass-and-discuss protocol: one person places, the next can move it, and so on. After a few minutes the buckets are the estimates.
Fails when the items vary in unknowns, not just size. Buckets work because placement is almost reflexive; anything that needs a real conversation gets dropped in the wrong bucket and stays there.
Dot voting
Everyone gets a fixed number of dots and places them on the items they care about most. It isn’t estimation — it’s prioritisation — but it gets confused with estimation often enough to be worth naming.
Fails when anyone reads the dot count as how big instead of how wanted. The output and the question don’t match, and using one as the other leaves you with a backlog full of small-but-popular items and large ones nobody owns.
Affinity mapping
The team sorts stories into piles by similarity of effort — no labels — then labels the piles (1, 2, 3, 5, 8…) by relative order once everything’s grouped. Sorting first and committing to numbers last is the whole idea: by the time the numbers arrive, the relative order is already settled, so the per-story argument — is this a 3 or a 5? — never starts. It’s fast, and almost as good as planning poker at avoiding anchoring.
Fails when the team can’t see each other’s piles. Affinity mapping leans on a shared wall or whiteboard; run it remotely in a tool with poor spatial awareness and people anchor on whoever places first — the exact failure it was meant to avoid.
Magic estimation
Magic estimation is affinity’s more decisive cousin: argue only where the team disagrees. Everyone silently places each story into a named size bucket, and the only stories that get a real discussion are the ones where the placements diverged. Stories the team agreed on in silence keep that silent consensus as their number.
That bet — that agreement in silence is real agreement — is the source of both the speed and the failure mode. When it holds, it’s the fastest technique that still produces real numbers: a 50-story backlog sized in half an hour. When it doesn’t, the team ships a unanimous 5 on a story that was secretly a mix of 3s and 8s, and nobody finds out until the sprint runs out.
Use it on long backlogs the team already understands, roadmap-level passes, and re-anchoring exercises. Avoid it on stories about to enter a sprint, or with a new team that hasn’t built a shared model yet — there, the silence hides exactly the disagreement you needed to hear.
#NoEstimates
Some teams skip story-point estimation entirely. The bet: if every story is broken down to roughly the same size — usually “fits in a day or two” — you can forecast by counting stories per sprint. It works, but only once the refinement is genuinely that sharp. It’s a graduation, not a shortcut.
Fails when story sizes drift and nobody notices. The whole approach relies on stories being uniform; without an estimation conversation, the signal that they’ve stopped being uniform never surfaces. The team that “doesn’t estimate” usually estimates implicitly, and badly.
Combining techniques in practice
Mature teams don’t pick one forever; they switch by the moment:
- T-shirts during quarterly roadmap planning.
- Affinity mapping, magic estimation, or buckets during a long backlog-refinement pass.
- Planning poker at sprint planning, when the stories at the top of the backlog need real shared understanding before anyone commits.
Pick the technique whose failure mode you’re willing to wear this quarter — not the one that came in the agile-coach’s slide deck.
Frequently asked questions
What are the main agile estimation techniques?
The common ones are planning poker, T-shirt sizing, the bucket system, affinity mapping, magic estimation, and — for prioritisation rather than sizing — dot voting. Some teams also run #NoEstimates, forecasting by counting same-sized stories instead of pointing them.
Which agile estimation technique is best?
There is no single best one; each fails differently. Planning poker is slow but builds shared understanding, T-shirts and buckets are fast but coarse, affinity and magic estimation are fast on large backlogs but hide disagreement. Pick the technique whose failure mode you can afford for the work in front of you.
What is affinity estimation?
Affinity estimation sorts stories into bigger-and-smaller piles first, with no numbers, then labels the piles at the end. Committing to numbers last is the whole point: by the time they arrive the relative order is settled, so the per-story argument never starts. It suits first-pass backlog sizing, not sprint commitment.
What is magic estimation?
In magic estimation the team silently places every story into a size bucket, and only the stories where placements diverged get a real discussion. The bet is that silent agreement is real agreement — which makes it very fast on a well-understood backlog and a poor choice for stories about to enter a sprint.
What is the difference between planning poker and T-shirt sizing?
Planning poker produces numeric story points through private voting and discussion, so it is slower but surfaces disagreement. T-shirt sizing (XS to XL) drops the granularity for speed, which suits early refinement and roadmap work — but T-shirts do not add up, so they cannot feed a velocity number.