Agile Estimation Techniques: Comparison Matrix
A one-page reference for picking an agile estimation technique: what each one optimizes for, the team size it suits, whether it feeds a velocity number, and the one-line case for using it. For the full reasoning behind every row, see the complete agile estimation guide.
The full comparison
| Technique | What it optimizes for | Team size | Feeds velocity? | Use it when... |
|---|---|---|---|---|
| Scrum Poker | Discussion depth on sprint-ready stories | 4-7 ideal | Yes (points) | Sizing stories entering the next sprint, with full context |
| T-shirt sizing | Speed over precision | Any, incl. non-engineers | Only with a size-to-point mapping | Roadmap-level sizing, or a room with non-engineers |
| Affinity estimation | Sizing a large backlog fast | Any | With a mapping | 50+ unrefined items need a rough order, silently and quickly |
| Bucket system | Very large backlogs (50+ items) | Any | With a mapping | Affinity estimation is still too slow one item at a time |
| Dot voting | Prioritization, not sizing | Any | No - different purpose | Deciding what matters most, not how big it is |
| Wideband Delphi | High-stakes, auditable estimates | Any, more formal | No, produces effort estimates directly | The estimate needs a documented, defensible rationale |
| Three-point (PERT) | A confidence interval, not consensus | Individual or small group | No, feeds schedule math instead | A stakeholder needs a schedule with a stated confidence range |
No row is universally "correct" - match the technique to the size of the backlog and how far along the cone of uncertainty the work has narrowed. Full explanation of every technique: agile estimation guide.
Match technique to team maturity
| Team stage | Favor | Why |
|---|---|---|
| New (first 1-3 sprints) | T-shirt sizing or affinity estimation | No shared baseline exists yet - precision from any technique is illusory |
| Established (steady velocity, 4+ sprints) | Scrum Poker | Enough reference points exist that a "5" means something consistent |
| Mature, large well-understood backlog | Lighter-weight or cycle-time tracking | Some teams drift away from points once the backlog is well understood |
Quick decision list
- Sizing sprint-ready stories with full context? Scrum Poker.
- Sizing a large, mostly-unrefined backlog fast? Affinity estimation or the bucket system, then Scrum Poker once items are sprint-bound.
- Roadmap-level, quarter-out, or a room with non-engineers? T-shirt sizing.
- An epic needs a schedule with a confidence range? Three-point estimation.
- A high-stakes estimate needs a documented rationale? Wideband Delphi.
- Deciding what to build, not how big it is? Dot voting - and recognize this isn't estimation at all.
Most mature teams end up combining two: a fast relative method to keep the backlog roughly ordered, and Scrum Poker for the stories entering the next sprint.
Run the default technique now
Scrum Poker is the default for a reason - private votes, one simultaneous reveal, and a real conversation about the spread. Create a free room and estimate five real backlog stories - no sign-up, every deck type included.