Agile estimation techniques: which one to use and when
A practical decision guide to agile estimation techniques: planning poker, story points, t-shirt sizing, affinity estimation and velocity, and which to use when.
Most teams argue about which estimation technique is “right.” That is the wrong question. Every technique trades something away: speed for precision, coverage for depth, a number for a conversation. The technique you pick is really the failure mode you have decided you can live with. So this page is a decision guide, not a ranking: what each technique is good at, how each one fails, and which to reach for in the situation in front of you.
Why estimate at all
Estimation gets a bad name because teams treat the estimate as a promise. It isn’t one. An estimate is a shared forecast: the team’s best current read on relative effort, made together so everyone carries the same picture into the sprint. Held that way, it helps you plan and it surfaces disagreement early, while it is still cheap to resolve.
Held as a commitment to be measured against later, it does the opposite. Every retrospective becomes a defense of a number, people learn to pad, and the estimate stops telling you anything true. So before you choose a technique, agree on what the number is for: a forecast you refine, not a contract you enforce. Get that straight and the choice of technique becomes a practical question rather than a political one.
Planning poker
Planning poker is the deliberate one. Each person privately picks a card, everyone reveals at once, and the spread starts the conversation. That private-vote-then-reveal step is the whole point: it catches the disagreement other techniques smooth over, and it keeps the senior person’s number from anchoring the room. The approach was popularized by Mike Cohn at Mountain Goat Software. Reach for it when you have a focused set of well-refined stories and you need shared understanding, not just a size.
Where it fails: speed. Planning poker is the slowest technique here, and unrefined stories turn that slowness into a refinement meeting wearing an estimation badge. If a story spreads from 3 to 13, you don’t have an estimation problem, you have a story that needs splitting.
Full walk-through: how to run planning poker. To run a session with your team right now, free, use planning poker for agile teams.
Story points
Story points are the unit most of these techniques produce, not a technique in themselves, and that distinction is worth holding onto. A point measures relative size: complexity, uncertainty, and effort rolled into one number, calibrated to the team’s own reference story rather than to hours. Planning poker, buckets, affinity and magic estimation all output points. T-shirt sizing deliberately does not.
Where it fails: the moment points get read as hours or compared across teams. Two teams sizing the same backlog land on different point numbers because they calibrate against different reference stories, so comparing the two measures nothing except how differently they set their zero.
Full chapter: what are story points.
T-shirt sizing
T-shirt sizing swaps numbers for categories: XS, S, M, L, XL. Dropping the granularity makes it fast, which is exactly what you want in early refinement, on roadmap work, and in conversations with product or leadership who do not need a decimal. It keeps a group moving at the stage where more precision would only be false precision.
Where it fails: t-shirts don’t add up. The moment someone outside the team needs a velocity number and you build a wiki table to convert L into 8, you have reinvented story points with extra steps.
Full chapter: t-shirt sizing.
Affinity estimation
Affinity estimation flips the usual order. The team sorts stories into bigger-and-smaller piles first, with no numbers, then labels the piles once everything is grouped. Committing to numbers last is the trick: by the time they arrive the relative order is already settled, so the per-story argument (is this a 3 or a 5?) never starts. It is fast, it scales to a large backlog, and it resists anchoring almost as well as planning poker. Magic estimation is its more decisive cousin: everyone places silently, and only the stories where placements diverged get a real discussion.
Where it fails: it hides disagreement. Silent agreement gets treated as real agreement, so a story that was quietly a mix of 3s and 8s can sail through as a unanimous 5, and nobody finds out until the sprint runs short. Run it remotely without a shared board and people anchor on whoever places first, which is the exact failure it was built to avoid.
Full chapter: affinity estimation (coming soon).
Velocity-based forecasting
Velocity is not a way to size stories; it is what you do with the points once you have them. It is the average number of story points a team completes per sprint over its recent history, and it exists for one job: projecting how many sprints a backlog will take. Sum the points remaining, divide by velocity, and you have a forecast grounded in the team’s actual rate rather than in wishful thinking.
Where it fails: the moment it becomes a target. Measure a team on velocity and it inflates, because the fastest way to raise the number is to size the same work bigger. That is Goodhart’s law running on a two-week cycle.
Full hub, with a calculator you can run your own numbers through: velocity.
Which technique when
Here is the short version. Match the situation to the technique that fits it, and go in already knowing how that technique fails, so the failure does not surprise you.
| Situation | Reach for | Why it fits | Watch out for |
|---|---|---|---|
| New team, still building a shared model | Planning poker | The discussion builds the shared reference the team doesn’t have yet | Slow; budget the time and keep stories small |
| Huge backlog to size in one pass | Affinity or magic estimation | Relative sorting handles volume far faster than voting each item | Silent agreement can hide real disagreement |
| Roadmap or quarterly planning | T-shirt sizing | Coarse categories match coarse certainty | Sizes don’t sum into a velocity number |
| A single tricky story | Planning poker | Private votes surface the hidden unknowns | A wide spread means split the story, not re-vote it |
| Committing to a sprint | Planning poker, then velocity | Shared sizing plus a forecast you can plan against | Don’t treat the commitment as a promise, or velocity as a grade |
Mature teams don’t pick one technique forever; they switch by the moment. T-shirts for the roadmap, affinity or magic estimation for the long refinement pass, planning poker at the top of the backlog when the next sprint’s stories need real shared understanding before anyone commits. Pick the failure mode you are willing to wear this quarter, not the one that came in the agile coach’s slide deck.
Estimate in TeamRetro
TeamRetro’s Estimations runs planning poker, t-shirt sizing, and the other techniques on this page in one place: private voting so nobody anchors on the loudest voice, a live reveal that starts the right conversation, and results that carry straight into your backlog. When you need the longer view, the same points feed velocity, so a season of estimates turns into a forecast you can actually plan against. Start a session with your team and see which technique fits the work in front of you.
Frequently asked questions
What are the main agile estimation techniques?
The ones most teams use are planning poker, t-shirt sizing, the bucket system, affinity estimation, and magic estimation. Most of them produce story points; t-shirt sizing produces categories (XS to XL) instead. Velocity sits alongside them as the forecasting step: it turns the points you estimated into a projection of how many sprints the backlog will take. Some teams also run #NoEstimates, forecasting by counting same-sized stories rather than pointing them, which works only once refinement is genuinely that sharp.
Which agile estimation technique is best?
It depends, and that is the honest answer rather than a dodge. There is no single best technique, because each one fails differently: planning poker is slow but builds shared understanding, t-shirt sizing and buckets are fast but coarse, affinity and magic estimation move quickly through a big backlog but can hide disagreement. The decision rule is simple. Pick the technique whose failure mode you can afford for the work in front of you. Sizing the next sprint’s stories, where a hidden disagreement is expensive, favors planning poker. Sizing a hundred-item backlog, where speed matters more than precision, favors affinity or magic estimation.
When should you use t-shirt sizing or affinity estimation instead of planning poker?
Use them when speed matters more than per-story precision and you are not about to commit the work to a sprint. T-shirt sizing suits early refinement, roadmap work, and conversations with product or leadership, where coarse sizes (XS to XL) match how much you actually know at that stage. Affinity estimation suits sizing a large backlog in one pass, because sorting stories into relative piles is far faster than voting each one individually. Planning poker earns its slower pace when the stories are about to enter a sprint and the cost of an unspoken disagreement is high. In short: t-shirts and affinity for breadth and speed, planning poker for the depth you need right before you commit.
Do all these techniques use story points?
No. Planning poker, the bucket system, affinity estimation, and magic estimation all output story points, numbers calibrated to the team’s own reference story. T-shirt sizing deliberately does not: it uses categories (XS to XL) precisely because they are coarse and do not add up, which keeps early conversations from implying a precision you don’t have yet. That is also its trade-off. Because t-shirt sizes don’t sum, they can’t feed a velocity number without a conversion table that quietly turns them back into points.