Posts

Agile estimation techniques: beyond planning poker

Planning poker gets most of the attention in agile estimation, and for good reason. But it's not the only option. Depending on your team size, the type of work, and how much time you have, other techniques might fit better. Here's what else is out there and when to use each one.

Planning poker (the baseline)

If you're already familiar with planning poker, you know the drill: the team discusses a backlog item, everyone privately selects a card representing their estimate, cards are revealed simultaneously, and outliers explain their reasoning. Repeat until you converge. Planning poker works well because simultaneous reveal prevents anchoring bias. The discussion that follows disagreement is where you actually learn things. Teams uncover misunderstood requirements and different assumptions about scope. It's the most reliable method for detailed sprint-level estimation. But it's slow. Estimating 30 backlog items one at a time can eat an entire afternoon. That's where the other techniques come in.

T-shirt sizing

T-shirt sizing replaces numeric scales with familiar labels: XS, S, M, L, XL, and sometimes XXL. Instead of debating whether something is a 5 or an 8, teams ask: "Is this a medium or a large?"

How to run it

1. Present the backlog items to the team
2. Start with a reference item everyone agrees on (e.g., "This login page redesign is a Medium")
3. For each remaining item, the team discusses and assigns a size relative to the reference
4. If there's disagreement, have the outliers explain their reasoning and re-vote

When to use it

T-shirt sizing works best early in a project when you need rough estimates for roadmap planning. It's faster than planning poker because there are fewer options to agonize over, and the labels discourage false precision. Nobody argues about the difference between an XL and an XXL the way they argue about 13 vs. 21 story points. It also works well for non-technical stakeholders. Product managers and designers intuitively understand "this is a Large" without needing a primer on Fibonacci sequences.

Affinity mapping (affinity estimation)

Affinity estimation lets teams size a large number of items quickly by comparing them to each other rather than to an absolute scale.

How to run it

1. Write each backlog item on a card or sticky note
2. Place the first item in the middle of a table or wall
3. Pick up the next item and ask: "Is this bigger, smaller, or about the same as the first?"
4. Place it left for smaller, right for larger, same column if similar
5. Continue with each item. Team members can silently rearrange items they disagree with
6. Once all items are placed, draw column boundaries and assign size labels to each group

The silent sorting phase is the secret. Instead of debating each item in sequence, multiple people move cards simultaneously. Disagreements surface naturally when someone moves a card and someone else moves it back. Those specific items become the discussion points.

When to use it

Affinity estimation is at its best when you have a large backlog (30+ items) and limited time. Teams can sort 50 items in 20-30 minutes, something that would take hours with planning poker. It's particularly useful at the start of a new project or after a big backlog grooming session.

Dot voting

Dot voting isn't strictly an estimation technique. It's a prioritization method. But it pairs well with estimation by helping teams quickly identify which items matter most.

How to run it

1. List all items on a board (physical or virtual)
2. Give each team member a fixed number of dots (typically 3-5)
3. Each person places their dots on the items they consider highest priority
4. Items with the most dots rise to the top

You can add constraints: "You can only put one dot per item" or "Put your dots on the items you think we should estimate first." Some teams use different colored dots for different dimensions (red for risk, green for value).

When to use it

Dot voting works best as a pre-estimation step. Instead of estimating your entire backlog, dot vote first to identify the top 10-15 items, then use planning poker or T-shirt sizing on just those. It saves time and keeps the team focused on what actually matters for the next sprint or release.

Bucket system

The bucket system combines elements of affinity mapping and planning poker. It's designed for estimating large backlogs quickly with larger groups.

How to run it

1. Create "buckets" representing estimate sizes (0, 1, 2, 3, 5, 8, 13, 20, 40, 100)
2. Pick one item and place it in a bucket as a reference (the team must agree on this one)
3. Deal the remaining items evenly among team members
4. Each person silently places their items into buckets relative to the reference
5. Once everything is placed, the team reviews together and discusses items that seem misplaced
6. Adjust and finalize

When to use it

The bucket system works well for large backlogs (50-200 items) with teams of 5-15 people. Because the initial sorting is done silently and in parallel, it's much faster than sequential estimation. The review phase keeps things honest without requiring discussion on every single item.

Three-point estimation (PERT)

Three-point estimation comes from project management, not agile. But it's useful when your team needs to account for uncertainty, especially on unfamiliar work.

How to run it

For each item, the team provides three estimates:

Estimate	Meaning
Optimistic (O)	Everything goes perfectly, no surprises
Most Likely (M)	Realistic scenario with normal friction
Pessimistic (P)	Everything that can go wrong does

The weighted average is: (O + 4M + P) / 6 For example, if a feature is estimated at 2 days optimistic, 5 days most likely, and 14 days pessimistic: (2 + 20 + 14) / 6 = 6 days.

When to use it

Three-point estimation is worth the overhead when uncertainty is high: unfamiliar technology, external system integrations, or something the team hasn't built before. The pessimistic estimate forces people to think about risks that planning poker often glosses over. It's overkill for routine work. If your team has built dozens of CRUD endpoints, you don't need three estimates for the next one.

Picking the right technique

There's no single best estimation method. The right choice depends on context.

Scenario	Best technique
Sprint planning with 10-15 items	Planning poker
Roadmap planning with rough sizing	T-shirt sizing
Large backlog (30+ items), limited time	Affinity mapping
Prioritizing what to estimate first	Dot voting
Huge backlog (50-200 items), large team	Bucket system
High-uncertainty work	Three-point estimation

Most teams end up combining techniques. Dot vote to prioritize, affinity map to rough-size the backlog, then planning poker the items in the upcoming sprint.

A few things that apply to all of them

No matter which technique you use:

• Estimate relative to each other, not in absolute terms. "This is twice as complex as that login page" is more useful than "this will take 3 days."
• Timebox the session. Estimation has diminishing returns. Set a timer and move on when you're close enough.
• Re-estimate when you learn something new. Estimates are snapshots, not commitments. Update them as requirements get clearer.
• Track accuracy over time. After a few sprints, compare estimates to actuals. The patterns will tell you where your team is consistently off. If your team consistently struggles with certain types of stories, an estimation complexity analyzer can help identify hidden complexity factors before you estimate.

If you want to try planning poker with your team, Kollabe's planning poker tool supports Fibonacci, T-shirt sizes, and custom scales, and it's free to start.