Planning Poker vs. T-Shirt Sizing vs. the Bucket System

"Which estimation technique should we use?" is one of those questions with an annoying answer: it depends. But it depends on things you can actually name — how many items you're sizing, how much precision you need, and how much time you have. Once you see what each method optimises for, the choice usually makes itself. Here's a practical comparison of the three most common approaches.

Planning Poker: precision through discussion

Planning Poker sizes items one at a time on a Fibonacci scale, with private votes revealed simultaneously. Its superpower is the conversation the reveal triggers — the spread between estimates surfaces hidden assumptions, dependencies, and risks. That makes it the best tool when understanding matters as much as the number.

• Best for: sprint-level refinement, a backlog of maybe 5–20 items, teams that benefit from discussing each story.
• Strengths: high-quality estimates, shared understanding, defeats anchoring and the HiPPO effect.
• Weakness: slow at scale. Estimating 200 items one by one will exhaust everyone.

T-shirt sizing: speed and approachability

T-shirt sizing swaps numbers for XS, S, M, L, XL. It's deliberately coarse, which is a feature: it removes false precision and lowers the stakes, so non-technical stakeholders happily join in. Because there are only a handful of sizes and no arithmetic, it's fast and unintimidating.

• Best for: early roadmap-level sizing, mixed audiences with product and business folks, a first pass before detailed estimation.
• Strengths: quick, intuitive, great for high-level planning and epics.
• Weakness: harder to sum for velocity; usually needs mapping to numbers eventually.

The Bucket System: estimating a lot, fast

The Bucket System is the one people rarely hear about, and it's a lifesaver when you have a large backlog. You lay out 'buckets' (often the Fibonacci numbers) as columns. The team places items into buckets through a fast, mostly silent divide-and-conquer process: a few items are seeded to calibrate, then everyone grabs items and drops them into the bucket that feels right, only pausing to discuss the genuinely contentious ones.

1. Seed the scale: estimate 3–4 reference items together and place them in buckets as anchors.
2. Divide and conquer: split the remaining items among the group; each person places their items by comparing to the anchors.
3. Sanity sweep: walk the buckets together, move any obvious misfits, discuss only the disputed items.

• Best for: huge backlogs — 50, 100, 200+ items — initial portfolio sizing, or clearing an estimation backlog that's fallen behind.
• Strengths: astonishingly fast for volume; can size hundreds of items in an hour.
• Weakness: less discussion per item, so lower per-item accuracy. Not for the delicate stories.

A worked example: one backlog, three altitudes

Here's how the three methods combined on a real project — a product team inheriting a 120-item backlog after a company merger. Estimating everything in Poker would have taken days, and nobody trusted the inherited numbers. So we layered the techniques instead.

1. Week 1, Bucket System: all 120 items sorted into Fibonacci buckets in a 90-minute session. Rough, fast, good enough to see the shape of the work and spot the monsters.
2. Week 1, T-shirt pass: the leadership group sized the 14 epics that emerged as XS–XL in half an hour — enough for a quarter-level roadmap conversation with stakeholders who'd never touched a point scale.
3. Ongoing, Planning Poker: each sprint, the top 8–12 stories get proper Poker treatment in refinement, with the bucket estimate as a starting hint but never as an anchor spoken aloud.

The layering matters more than any single method. Bucket gave breadth, T-shirts gave a stakeholder language, Poker gave depth exactly where depth paid off. Total estimation overhead: about three hours up front, then a steady 30–45 minutes per sprint.

What about #NoEstimates and the others?

Two other approaches deserve an honest mention. Affinity mapping is a close cousin of the Bucket System — items are silently grouped by similarity first, sized after — and shines when the backlog is full of near-duplicates. And the #NoEstimates school argues for skipping size estimates entirely: slice stories small and roughly equal, count throughput, and forecast from that. For mature teams with disciplined slicing, it works. But notice what it quietly requires — the ability to slice consistently small, which is itself a skill teams usually build by estimating for a few years first. Estimation is the training wheels that teach the slicing; some teams eventually take the wheels off, and that's fine.

A simple way to choose

Don't overthink it. Match the method to the volume and the stakes:

Can you switch methods mid-project?

Yes — and teams worry about this far more than they should. Because all three techniques are relative scales, the underlying skill (comparing new work against known work) transfers completely; only the labels change. The one thing to protect during a switch is your velocity history. If you move from T-shirts to points, re-size a handful of recently completed stories in the new scale to establish continuity, and treat the first sprint's velocity as provisional. What you should not do is run two scales in parallel for the same backlog level — a board where some stories wear an 'M' and others a 5 forces everyone to do mental currency conversion, which is precisely the overhead these techniques exist to remove.

Try the two that need a tool

Planning Poker and its Fibonacci and T-shirt decks are exactly what this site is built for. You can start a free session and switch between a numeric or T-shirt deck when you create it. If you're still deciding whether relative estimation is right for your team at all, start with what Planning Poker is.