Agile Estimation Techniques: Planning Poker, T-Shirt Sizing and More

What are agile estimation techniques, and why do they rely on relative sizing?

Agile estimation techniques are structured ways for a delivery team to size work without pretending to know exactly how many hours it will take. They compare a new item to items the team has already delivered, producing a unit — story points, t-shirt sizes, buckets — that stays meaningful as the team’s speed changes.

Absolute estimation fails for three predictable reasons. The same task takes a senior developer four hours and a junior two days. Unknown-unknowns only appear once work starts. And once an hour estimate becomes a commitment, the person giving it learns to pad it.

Relative sizing sidesteps all three. Humans are poor at predicting duration but good at comparing two things they can both see: if story A took three days and B looks twice as tangled, “B is roughly double A” survives contact with reality far better than “B will take six days.”

The anchor matters more than the scale. Pick two or three reference stories the team remembers — one small, one medium, one awkward — and size everything against them. Without anchors, one person’s medium is another person’s large.| Technique | Output | Typical pace | Best used for | Main weakness |

How does planning poker work, step by step?

Planning poker is a consensus technique in which every team member privately chooses a card, all cards are revealed at the same moment, and the highest and lowest voters explain their reasoning before a re-vote. James Grenning named the method in 2002; Mike Cohn popularised it in *Agile Estimating and Planning* in 2005.

Grenning’s problem was not accuracy: in an eight-person planning session, two senior engineers dominated for nearly an hour while the other six mentally left the room. His fix was procedural — everyone gets cards, nobody speaks during the vote, and the numbers land together.

The mechanics that make it work:

1. The product owner presents one item and does not vote. They answer questions, then stop talking.
2. The team discusses for a fixed time — two minutes is enough. Implementation debates belong in refinement.
3. Everyone selects a card face down. Nobody sees a number before committing to their own.
4. All cards turn over at once. This is the whole mechanism; sequential voting reintroduces anchoring.
5. The lowest and highest voters explain first. Not the loudest, not the most senior.
6. The team re-votes. Two rounds usually converge; three is the limit.
7. If it still will not converge, the item is too big or too vague. Split it and estimate the pieces.

That last rule saves more time than any other. Persistent disagreement is rarely a rounding dispute; it is evidence that two people are imagining different work.

Why does planning poker use Fibonacci numbers?

The Fibonacci-like deck — 1, 2, 3, 5, 8, 13, 20, 40, 100 — is used because the gaps grow as the items grow, which mirrors how uncertainty actually behaves. It also removes arguments that cannot be settled: no team can defend the difference between a 6 and a 7, so the scale refuses to offer the option.

Doubling would be worse: a scale of 5 and 10 claims a precision the team does not have, while Fibonacci forces a choice between 8 and 13, which is the honest shape of the judgement. Most commercial decks also replace 21, 34 and 55 with 20, 40 and 100, because three significant figures imply a confidence nobody has.

What does the research say? Less than the training material implies. A 2012 study in the *Journal of Systems and Software* opened with the observation that “there is little empirical evidence regarding the accuracy of planning poker estimates” and then tested the technique with 13 student teams. The pattern across the literature is consistent: group estimation improves shared understanding more reliably than it improves the number, which is why the Project Management Institute’s Disciplined Agile guide states that “understanding is more important than accuracy.”

Popularity is not in doubt, though. A 2025 survey of 93 agile practitioners in Sri Lanka found planning poker the most-used technique at 50.5% and story points the most-used unit at 61.3%.

When is t-shirt sizing the better tool?

T-shirt sizing is better whenever the work is early, large, or being discussed with people outside the delivery team. It replaces numbers with categories — XS, S, M, L, XL — so nobody mistakes a size for a duration, and a marketing lead can call an initiative a Large without understanding story points. That makes it the right tool for quarterly roadmaps, epic-level triage and the first pass over a backlog nobody has refined.

Treat XL as a flag rather than a size. When an item comes back XL, the next question is “what smaller piece of this delivers value on its own?” A backlog where most items are L or XL is not a plan; it is a list of intentions.

One warning: never convert sizes into points to claim a velocity figure. The conversion reintroduces exactly the false precision the sizes were meant to remove.

How do affinity grouping, the bucket system and dot voting fit in?

These three techniques are for breadth. They help a team get a fast, shared picture of a large body of work, and they are a poor substitute for the per-item discussion that planning poker forces.

Affinity grouping (sometimes called silent sorting) puts every item on a card, has the team arrange them in relative order without speaking, then draws size boundaries through the resulting line. A team that would spend four hours estimating 60 items at four minutes each can sort the same 60 in 20 to 30 minutes. The trade-off is real: you get order and rough size, but almost no discussion of individual items, so the risky ones stay hidden until refinement.

The bucket system adds labelled swim lanes (XS through XL) and a divide-and-conquer loop: place a few items together, then split the remainder into smaller groups that sort against the emerging anchors. It scales to 50–200 items and works with groups larger than a dozen people.

Dot voting is not an estimation technique at all. Give everyone three dots, vote on which items to estimate first, then poker only the top 10–15. Used this way it saves whole sessions; used as a sizing method it produces noise. A workable sequence for a messy 150-item backlog: dot vote the quarter’s candidates, affinity-sort those 40, then poker the 12 entering the next two sprints.

Story points or hours: which unit should you estimate in?

Use story points for the team’s own forecasting and hours for the people who must staff and pay for the work — but never publish a conversion factor between them. The two units answer different questions, and forcing them into one number breaks both.

The mechanism worth understanding: when a team automates its test suite and gets 20% faster, velocity rises from 32 to roughly 38 points per sprint while the points attached to each story stay the same. The scale absorbed the improvement automatically. An hours-based backlog would need re-estimating from scratch.

That stability is also why points must never become an individual performance metric. The moment points are attached to a person, the estimates inflate and the forecast becomes fiction.

> Common mistake: Publishing “1 point = 6 hours” in a management report. It converts the team’s relative scale back into a fixed-price contract, and within two sprints the team is arguing about hours again with extra steps.

What does estimation look like with real numbers?

Three worked examples, all reproducible with a calculator.

Example 1: one story, two rounds. Six people vote. Round one: 5, 5, 8, 5, 13, 5. The median is 5, but the 13 must explain itself. The reason: the acceptance criteria omit a migration of 40,000 legacy records, and one developer has done that migration before. Round two: 8, 8, 8, 5, 8, 8 — the team settles on 8, then splits the story into an 8 for the feature and a separate 5 for the migration. Twenty-two minutes here prevented a sprint overrun that would have cost several days.

Example 2: forecasting from velocity. The last four sprints delivered 31, 36, 28 and 33 points. Total 128, average 32. The selected backlog is 37 points. Committing to 37 plans against the average and ignores the variance. Committing to 28 — the worst recent sprint — gives a defensible commitment and a stretch target of 36. On the average, 37 points takes 37 ÷ 32 = 1.16 sprints; at the low end, 37 ÷ 28 = 1.32, a real chance of spilling into a third sprint.

Example 3: cost per point. Six people at a fully loaded $95 per hour, 40 hours a week, cost $22,800 per week. A two-week sprint costs $45,600, which at 32 points is $1,425 per point.

A 120-point epic then takes 120 ÷ 32 = 3.75, so four sprints at $182,400. If velocity slips to 28 points, the same epic takes 4.3 sprints, so five sprints at $228,000 — a $45,600 difference caused entirely by throughput. That is the number to bring to a steering meeting when someone asks why estimation discipline matters.

What are the trade-offs and the most common mistakes?

Every technique here buys speed with precision or precision with time. These are the mistakes that reverse that trade.

• Estimating the entire backlog. A 300-item backlog does not need 300 estimates. Estimate the next two sprints and rough-size the rest.
• Averaging instead of converging. The average of 5 and 13 is 9, a number nobody voted for. Convergence means the 13 was heard, not cancelled out.
• Voting in sequence. “I’ll go 8, what do you think?” destroys the only protection the method has against anchoring.
• Converting points to hours for reporting. Still the most common way organisations break their own estimation system.
• Comparing velocity between teams. Points are calibrated to one team’s reference stories, so Team A’s 40 and Team B’s 40 are unrelated numbers.

The honest trade-off: planning poker costs two to five minutes per item, so a 40-item refinement can consume three hours of team time. Affinity grouping would take 25 minutes. Choose poker when the cost of an unspoken disagreement is high — exactly the work entering the next sprint — and sorting when you need the shape of a quarter.

How do you keep estimates honest across sprints?

Keep estimates honest by measuring what happened, publishing velocity as a range, and reviewing the gap in the retrospective instead of the planning meeting. Estimation improves through feedback loops, not more careful guessing.

Three habits do most of the work. Count only accepted work as done, because a story that is 90% complete adds zero to velocity and 100% to the illusion of progress. Use a three-sprint rolling window rather than an all-time average. And separate forecast from commitment in writing: “we forecast 34 points and commit to 28” prevents a dozen painful conversations.

> Practical tip: Keep a one-line note on every large miss. “13 became 21 because the vendor API returned paginated results we had not seen.” Twelve of those notes are worth more than any estimation course.

How do you run estimation with a distributed team?

Distributed estimation works when the backlog, the discussion and the resulting velocity live in one place. When stories are in one tool, the debate happens in a chat thread, and velocity is recalculated in a spreadsheet, the numbers arrive late and nobody trusts them.

Doitify is built for that gap: backlogs and sprints, multi-level tasks and sub-tasks, checklists, owners and progress reports in one workspace, plus a Copilot that can draft sub-tasks from a story description before the team votes. It does not replace the conversation — nothing should — but it removes the reconciliation step.

Doitify is our product, so weigh that accordingly. A team with a working backlog tool and a trusted velocity chart does not need to switch anything to estimate well.

Conclusion

Agile estimation techniques are not competing religions; they are tools with different costs. Planning poker buys shared understanding at two to five minutes per item. T-shirt sizing and affinity grouping buy breadth at the price of detail. The bucket system buys scale, and dot voting buys focus.

Pick by asking what a wrong number would cost you. For the twelve stories entering the next sprint, the answer is usually “a wasted two weeks,” so use poker and let the outliers talk. For a 150-item roadmap, the answer is “very little,” so sort it in half an hour.

Then do the unglamorous part: measure what happened, keep velocity as a range, and write down why the big misses missed. Teams that do that estimate better every quarter without ever becoming more precise.

If this post on agile estimation techniques was helpful, you might also enjoy Project Schedule vs Project Plan: Key Differences Explained and Workplace Productivity Statistics for 2026.