Agile estimation techniques compared

Every estimation technique is a trade. The technique you pick is the failure mode you've decided you can afford.

Quick comparison

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 disagreement other techniques smooth over. Background: our Planning Poker guide.

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 you're voting and 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 ditched the granularity. Common in early refinement, in product/leadership conversations, and on teams that have made a deliberate move 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 points with extra steps. See story points vs t-shirt sizing.

Bucket system

The team drops items into pre-labeled buckets (1, 2, 3, 5, 8…) with a fast pass-and-discuss protocol: one person places, the next can move, and so on. After a few minutes the buckets are the estimates. (Buckets usually follow a Fibonacci or modified Fibonacci scale.)

Fails when: the items vary in unknowns, not just size. Buckets work because the placement is almost reflexive. Anything that needs a real conversation gets parked in the wrong bucket and stays there.

Dot voting

Everyone gets a fixed number of dots and places them on items they want to prioritize. It's not estimation — it's prioritization — but it gets confused with estimation often enough to mention.

Fails when: anyone reads the dot count as "how big" instead of "how wanted." The output and the question don't match; using one as the other produces backlogs full of small-but-popular items and large items that nobody owns.

Affinity mapping

The team silently sorts stories into piles by similarity of effort, no labels. Once everything's grouped, you label the piles (1, 2, 3, 5, 8…) by relative order. Fast, and almost as good at avoiding anchoring as Planning Poker.

Fails when: the team can't see each other's piles. Affinity mapping leans on physical co-location or a shared whiteboard. Remote teams running it in a tool with poor spatial awareness end up anchoring on whoever places first — the same failure mode it was supposed to avoid.

#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 after the refinement work is already done. It's a graduation, not a shortcut.

Fails when: story sizes drift and nobody notices. The whole technique relies on stories being the same size; without an estimation conversation, the signal that they've stopped being uniform never surfaces. The team that "doesn't estimate" usually estimates implicitly, badly.

How teams actually combine these

In practice, mature teams run more than one of these depending on the moment:

• T-shirts during quarterly roadmap planning.
• Affinity mapping or buckets during long backlog refinement.
• 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. Don't pick one because it's the one in the agile-coach deck.