The techniques at a glance
Every technique below trades speed against precision differently. Planning poker is slow and discussion-rich; affinity and bucket estimation are fast at scale; throughput forecasting skips relative sizing entirely. Scan the table, then read the decision guidance underneath.
| Technique | How it works | Best for | Watch out for |
|---|---|---|---|
| Planning poker | Independent voting on a Fibonacci-style deck, simultaneous reveal, discuss and re-vote until consensus. | Refinement-sized batches where discussion adds value and the team shares context. | Slow for large backlogs; needs a facilitator to keep discussion timeboxed. |
| Affinity estimation | Silently sort stories into relative size groups on a wall or board, then label the groups with points. | Sizing 50+ stories in one sitting when you need speed over per-story debate. | Loses the discussion that surfaces hidden assumptions; needs a follow-up pass on outliers. |
| Bucket estimation | Place stories into predefined "buckets" (e.g. 1, 2, 3, 5, 8, 13) as a group, one story at a time, moving fast. | Medium-to-large backlogs that still want a scale but can't afford full poker. | Early buckets anchor later ones; quality depends on a disciplined facilitator. |
| T-shirt sizing | Estimate with XS–XL sizes instead of numbers; optionally map to points later. | New teams, fresh domains, and stakeholder-facing rough sizing. | No native arithmetic for velocity; needs a mapping step to forecast. |
| Throughput forecasting | Skip sizing; count how many stories the team completes per sprint and forecast from that history. | Teams with a steady flow of similarly-sized stories and reliable history. | Needs consistent story sizes and enough data; weak for one-off or novel work. |
When planning poker is the right call
Reach for planning poker when the discussion is the point — when your stories carry real uncertainty and the team benefits from surfacing assumptions before committing. It shines on refinement-sized batches of five to fifteen stories, where the conversation catches problems early. It's the wrong tool for sizing a hundred-story backlog in an hour: the per-story discussion that makes it valuable also makes it slow.
When affinity or bucket estimation wins
When you have a large backlog to size quickly — a new project, a migration, a quarter's worth of ideas — affinity and bucket estimation are built for volume. Affinity's silent relative sort can size dozens of stories in the time poker spends on three. Bucket estimation keeps a numeric scale while moving nearly as fast. The trade is discussion: both skip the assumption-surfacing that poker does, so plan a short follow-up pass to re-examine the outliers and anything that landed in a surprising group.
When to size with T-shirts
T-shirt sizing fits teams that are new, in an unfamiliar domain, or estimating for stakeholders who don't care about points. It removes false precision and reduces the "5 vs. 8" debates that stall numeric decks. The cost is arithmetic: you can't sum XL + M into a velocity, so you'll eventually map sizes to points if you need to forecast. Many teams start here and graduate to Fibonacci once they've got a few sprints of reference stories.
When to stop estimating and measure flow
If your stories are already small and similar, story-point estimation can be pure overhead — you spend meeting time producing numbers a throughput count would give you for free. Teams practicing this (sometimes under the #NoEstimates banner) split stories until each is roughly the same small size, then forecast from how many they finish per sprint. It demands discipline in splitting stories and enough history to be reliable, and it's weak for genuinely novel work — but for steady delivery streams it's the least-effort forecast that works.
How to choose
Match the technique to the batch, not the other way around. Use affinity or bucket estimation for the big initial sizing pass, planning poker for the weekly refinement of the stories about to be built, and throughput forecasting once your flow is steady enough to trust. These aren't mutually exclusive — mature teams switch between them by context. The comparative research on agile estimation approaches and the PMI's survey of estimation techniques both land on the same conclusion: no single method is best in all cases, so the useful skill is knowing which one to pull out when. If you settle on relative sizing, Pokor supports Fibonacci, T-shirts, Powers of 2, and custom decks so you can run whichever fits.