April 29, 2026· 7 min read

Scrum Estimation Techniques Compared

Planning poker, T-shirt sizing, dot voting, bucket system — a clear comparison of the most effective Scrum estimation techniques and when to use each one.

Agile teams have invented a surprising number of ways to estimate work. Most of them solve the same core problem: how do you get a group of people with different knowledge and assumptions to agree on how hard something is, without the loudest voice winning?

Here is a clear comparison of the most widely used Scrum estimation techniques — what they are, how they work, and when to use each one.

1. Planning poker

Planning poker is the most popular estimation technique in Scrum. Team members vote simultaneously using Fibonacci-scale cards (1, 2, 3, 5, 8, 13, 21), outliers explain their reasoning, and the team converges through discussion.

Best for: Sprint-level estimation of well-defined user stories. The discussion it generates is its main value, not just the number.

Weakness: Slower than other methods. Estimating 50 items in a single session is not realistic.

2. T-shirt sizing

T-shirt sizing uses clothing sizes (XS, S, M, L, XL) as estimation buckets. It is fast, intuitive, and requires no calibration — everyone understands the scale immediately.

Best for: Roadmap planning, early backlog grooming, or any context where you need rough relative sizing on a large number of items quickly.

Weakness: Too imprecise for sprint capacity planning. Does not feed naturally into velocity tracking.

For a deeper comparison, see Planning Poker vs T-Shirt Sizing.

3. Dot voting

Each team member gets a fixed number of dots (stickers, or clicks in a digital tool) to distribute across backlog items. Items with the most dots are considered the highest priority or largest in scope, depending on how the session is framed.

Best for: Prioritization exercises, not estimation. Dot voting answers "what should we do first?" better than "how hard is this?"

Weakness: Does not produce effort estimates. Often misused as a substitute for a real estimation session.

4. The bucket system

Stories are physically sorted into buckets (columns on a board) labeled with Fibonacci numbers. The team places each item into a bucket relative to stories already placed. Items that everyone agrees on move fast; items that generate disagreement get discussed.

Best for: Estimating large backlogs quickly — 100+ items in a single session. Much faster than planning poker at scale.

Weakness: Less discussion per item. Works best when the team has already established a shared understanding of the scale through previous planning poker sessions.

5. Affinity mapping

Stories are sorted into groups silently — team members move items around on a board without speaking. Once the sorting stabilizes, the team labels each group with a size. The silence prevents anchoring and social pressure.

Best for: Teams that have strong anchor bias problems, or where one or two people tend to dominate discussion.

Weakness: Works better in person than remotely. Requires a physical or digital board that everyone can manipulate simultaneously.

6. Three-point estimation

For each story, the team estimates three numbers: the optimistic case (O), the most likely case (M), and the pessimistic case (P). The final estimate is calculated as (O + 4M + P) / 6 — a weighted average that accounts for uncertainty.

Best for: High-stakes projects where understanding the range of outcomes matters, or where the team has significant uncertainty about specific items.

Weakness: Slower and more complex. Overkill for most sprint planning sessions. Better suited to project-level estimation than story-level.

Which technique should you use?

There is no universally correct answer. Most experienced agile teams use different techniques at different levels: T-shirt sizing for quarterly roadmaps, planning poker for sprint backlog refinement, and the bucket system when they need to estimate a large backlog quickly.

The technique matters less than the discipline of doing it consistently, using historical velocity as feedback, and treating wildly divergent estimates as signals to investigate rather than numbers to average away.

If you are starting out, begin with planning poker. It is the most widely understood, generates the most useful discussion, and has the best tooling support. Switch to others as your team matures and your backlog grows.

Try it now

Run your next planning poker session in 30 seconds.

No account, no setup, no nonsense — just paste the link to your team and vote.

Start a free session →
Buy me a coffee