Learning Objectives
By the end of this lesson you will be able to:
- Describe T-shirt sizing and when to apply it
- Explain the #NoEstimates movement's core argument
- Facilitate an Affinity Mapping estimation session
- Choose between estimation methods based on team maturity and project phase
Why Alternatives Exist
Planning Poker is a good default. But it's not the only tool, and it's not always the best one. Different situations call for different approaches:
- Early exploration: You need rough sizing, not precise estimates
- Large backlog grooming: You need to size 50+ stories quickly
- Team dysfunction: Planning Poker itself has become the source of conflict
- High-trust, mature teams: The overhead of formal estimation outweighs the benefit
Method 1: T-shirt Sizing
Instead of Fibonacci numbers, use sizes: XS, S, M, L, XL, XXL.
How it works:
- Each size represents a rough relative bucket, not a precise number
- Teams first agree on a "reference story" for each size (e.g., "An M is about as complex as adding a new filter to the search page")
- Stories are then placed into buckets relative to the references
When to use it:
- Initial roadmap estimation (months out, when precision is meaningless)
- Backlog grooming for a large, newly prioritized batch of stories
- With stakeholders who don't have context on Story Points
Limitation: T-shirt sizes don't aggregate easily. You can't directly compute sprint capacity. The usual solution is to map sizes to points for planning purposes (e.g., S=2, M=5, L=8, XL=13).
Pro Tip: T-shirt sizing works best when you resist the urge to be precise. "Is this an M or an L?" should take 30 seconds, not 10 minutes. If you're spending more than that, the story needs refinement, not better estimation.
Method 2: #NoEstimates
The #NoEstimates movement argues that for many teams, the cost of estimation (time, meetings, false precision) exceeds the value. Instead of estimating story points, teams:
- Count stories (assuming roughly similar size after good slicing)
- Use Cycle Time averages to forecast: "We close ~8 stories per sprint; we have 40 stories left; ~5 sprints to complete"
- Focus refinement energy on slicing stories to similar sizes rather than assigning numbers
When it makes sense:
- Mature teams with strong slicing discipline
- High-certainty backlogs where stories are consistently well-defined
- When historical data (Cycle Time, throughput) is available for forecasting
When it doesn't make sense:
- New teams without historical data
- Teams where story sizes vary wildly
- Contexts where stakeholder communication requires point-based forecasts
The nuanced view: #NoEstimates isn't anti-forecasting. It's anti-fake-precision. Using count + Cycle Time for forecasting is still forecasting — just with metrics that have less noise.
Method 3: Affinity Mapping
A fast, high-participation method for sizing a large backlog.
How it works:
- Write each story on a card (sticky note or digital card)
- One person places the first card somewhere on a spectrum (left = small, right = large)
- Each subsequent card is placed relative to the existing ones: "Is this bigger or smaller than X?"
- No discussion during placement — just silent relative ordering
- After all cards are placed, the group draws lines to create buckets (these become your size groups)
- Discussion only happens when someone disagrees with a placement
Why it's fast: Most estimation time is spent debating. Affinity Mapping uses silent parallel processing — everyone moves cards at once or takes turns quickly without discussion. A team of 6 can size 40 stories in 30-40 minutes.
When to use it:
- Sprint 0 / project kickoff
- Quarterly planning with a new batch of epics
- When Planning Poker would take too long for the volume of items
Choosing the Right Method
| Situation | Method |
|---|---|
| New team, first sprint | Planning Poker (builds shared understanding) |
| Large batch, rough sizing | T-shirt Sizing or Affinity Mapping |
| Mature team with good data | #NoEstimates / throughput forecasting |
| Backlog has wild size variation | Fix the slicing first, then any method works |
| Planning Poker debates consuming sessions | Affinity Mapping or T-shirt Sizing |
Summary
Estimation methods are tools, not religions. Planning Poker is a useful default that builds shared understanding. T-shirt sizing is faster for rough cuts. Affinity Mapping scales to large batches. #NoEstimates makes sense when you have the data and discipline to replace story points with throughput metrics. The best teams try multiple approaches and keep what works.