Agile estimation techniques compared
There is no single best way to estimate in agile. This guide compares the most common estimation methods in Scrum and similar frameworks, and explains when each one fits.
Agile teams estimate for two reasons: to decide what fits in the near future, and to have a useful conversation about the work. Different agile estimation techniques balance those goals differently. Some are precise but slow, others are fast but rough. This guide walks through six common estimation methods used in Scrum and other agile frameworks, compares them side by side, and gives practical advice on how to pick.
Planning poker
In planning poker, each team member privately selects a card with their estimate, usually in story points on a Fibonacci-like scale. Everyone reveals at once, the lowest and highest voters explain their reasoning, and the team votes again until it converges.
Strengths: independent estimates prevent anchoring; the discussion surfaces hidden risks; everyone participates.
Weaknesses: it takes a few minutes per story, so it is slow for large backlogs.
Best for: refined stories heading into the next sprint or two.
T-shirt sizing
T-shirt sizing uses sizes like XS, S, M, L and XL instead of numbers. Items are sized relative to each other, often with a quick vote.
Strengths: fast, intuitive, easy for stakeholders to understand.
Weaknesses: sizes cannot be added up, so they are not enough for sprint-level forecasting without a conversion.
Best for: roadmaps, early backlogs, and conversations with non-technical stakeholders.
Affinity estimation
In affinity estimation, the team lays all the items out and arranges them on a wall (or virtual board) from smallest to largest. First, items are placed in silence, one at a time, and anyone can move an item they disagree with. Then the team discusses items that keep moving back and forth. Finally, the ordered line is divided into groups, and each group gets a size or point value.
Strengths: handles dozens of items in one session; comparing everything at once keeps sizes consistent.
Weaknesses: less discussion per item, so individual estimates are rougher; the silent phase can be dominated by whoever moves fastest.
Best for: sizing a large backlog for the first time, or re-baselining after a big change.
Bucket system
The bucket system is similar to affinity estimation but starts from fixed buckets labelled with values, often a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20, 40, 100). The team places one item in the middle as a reference, then each person takes items and places them in the bucket they think fits, with a short round of review and adjustment at the end.
Strengths: very fast for large numbers of items; produces numbers that can be summed.
Weaknesses: people often place items alone, so some estimates reflect one person's view.
Best for: large backlogs where you need rough numbers quickly, such as release planning.
Dot voting
In dot voting, each participant gets a fixed number of dots and places them on items. In an estimation context, dots can indicate perceived size or effort; more commonly, dot voting is used to prioritize rather than to size.
Strengths: extremely quick; works with any group, including stakeholders.
Weaknesses: it measures opinion, not size, and is easily swayed by people voting after seeing others' dots.
Best for: narrowing down which items to estimate properly, or quick prioritization.
#NoEstimates
#NoEstimates is a movement in the agile community that questions whether detailed estimates are worth their cost. Instead of estimating each item, teams split work into small items of roughly similar size and forecast by counting items completed over time (throughput).
Strengths: no time spent on estimation meetings; forecasting is based on actual delivery data.
Weaknesses: requires discipline in splitting work consistently and some history of throughput; it can lose the shared conversation that estimation sessions create.
Best for: mature teams with a steady flow of small, similar-sized work.
Comparison table
A quick summary of how these estimation methods compare. Speed and precision are relative to each other, not measured values.
| Technique | Best for | Speed | Precision |
|---|---|---|---|
| Planning poker | Refined stories for upcoming sprints | Slow to medium | High |
| T-shirt sizing | Roadmaps, early backlogs, stakeholder conversations | Fast | Low to medium |
| Affinity estimation | Sizing a large backlog for the first time | Fast | Medium |
| Bucket system | Rough numbers for many items, release planning | Very fast | Medium |
| Dot voting | Quick prioritization, narrowing a list | Very fast | Low |
| #NoEstimates | Teams with steady flow of small, similar items | No estimation time | Depends on consistent splitting |
How to pick an estimation technique
Match the method to the decision
Ask what the estimate will be used for. Deciding whether a feature belongs on this year's roadmap needs a rough size, so t-shirt sizing or the bucket system is enough. Deciding what goes into next sprint needs more care, so planning poker is a better fit.
Match the method to the number of items
Planning poker on 100 items would take an entire day. For large lists, use affinity estimation or the bucket system first, then planning poker only for the items that are about to be worked on.
Combine methods
Many teams use a funnel: dot voting or t-shirt sizing for the long list, then planning poker for the top of the backlog. For example, a team might size "Add password reset by email" as an M during roadmap planning, then estimate it as a 5 in planning poker once acceptance criteria are written.
Consider your team
New teams often benefit from the discussion planning poker forces. Experienced teams with stable, small stories may find they can estimate less, or move toward counting items.
Review regularly
Use your retrospective to ask whether estimation is helping. If sessions feel long and estimates rarely change decisions, try a lighter technique. If sprints keep overflowing, you may need more conversation, not less.
Summary
Each technique trades speed for precision differently. Planning poker gives the best conversation per story; t-shirt sizing, affinity estimation and the bucket system handle volume; dot voting helps prioritize; #NoEstimates removes estimation in favour of small, consistent work. When you are ready to try planning poker or t-shirt sizing online, you can start a free session and invite your team with a link, or read how to run planning poker with a remote team.
Frequently asked questions
What is the most common agile estimation technique?
Planning poker with story points on a Fibonacci-like scale is one of the most widely used techniques in Scrum teams, often combined with t-shirt sizing for early backlog work.
Which estimation method is fastest for a large backlog?
The bucket system and affinity estimation are designed for large numbers of items and are much faster than estimating each item with planning poker.
What is #NoEstimates?
#NoEstimates is an approach that questions the value of detailed estimates. Teams split work into small, similar items and forecast by counting how many items they complete over time.
Can we use more than one estimation technique?
Yes, and many teams do. A common pattern is rough sizing such as t-shirt sizes for the long backlog, then planning poker for stories about to enter a sprint.