Guide · 5 min read · Updated 2026-09-02
Fibonacci vs T-shirt sizing
Both scales exist for the same reason: humans are bad at precise estimates and good at relative comparisons. The difference is how much precision you pretend to have, and who the estimate is for.
Side by side
| Fibonacci | T-shirt | |
|---|---|---|
| Values | 1, 2, 3, 5, 8, 13, 21… | XS, S, M, L, XL |
| Best for | Sprint backlog, velocity tracking | Roadmaps, epics, early discovery |
| Maths | Sums to a sprint total | Needs conversion first |
| Learning curve | Medium | Very low |
| Main risk | Numbers get read as hours | Too coarse for planning a sprint |
Why Fibonacci and not 1–10?
The gaps between Fibonacci values grow as the numbers grow, which mirrors how uncertainty actually behaves. You can genuinely tell a 1 from a 2. You cannot tell a 17 from an 18 — and a scale that offers both invites a pointless argument. By forcing a jump from 13 to 21, the scale makes the team say "it's much bigger" instead of haggling over noise.
The practical ceiling matters too. Anything landing on 21 or above is a signal to split the story rather than a number to plan with.
When T-shirt sizes win
T-shirt sizing removes numbers entirely, which is exactly what you want when the work is still fuzzy. It is the better choice when:
- You are shaping a roadmap or quarter and comparing initiatives, not stories.
- The team is new to estimation and numbers trigger a false sense of commitment.
- Non-engineering stakeholders take part and need a scale they read intuitively.
- You are triaging a large, unrefined backlog quickly before deeper refinement.
When Fibonacci wins
- You track velocity and want sprint capacity to be a simple sum.
- Stories are refined enough that relative differences are real.
- You want forecasting data — points per sprint over time is a usable trend line.
- Your tracker (Jira, Linear, Azure DevOps) expects a numeric story-point field.
Using both without confusion
Many teams run T-shirt sizes at the epic level and Fibonacci at the story level. That works well as long as you never treat one as an exact conversion of the other. A common rough mapping:
- XS ≈ 1
- S ≈ 2–3
- M ≈ 5
- L ≈ 8–13
- XL ≈ 21+ (split it)
Publish the mapping once, keep it visible, and revisit it every few months — the meaning drifts as the team's reference stories change.
Anchor on a reference story either way
Neither scale means anything on its own. Pick one recently completed story everyone remembers, declare it the anchor (a 3, or an M), and estimate everything against it. When new people join, re-establish the anchor before the first session or the whole scale quietly shifts.
Switching scales mid-project
Do not retro-convert your history. Freeze the old numbers, start the new scale from the next sprint, and accept that velocity needs three or four sprints to stabilise again. Converting past estimates produces a trend line that looks precise and means nothing.
Try both in the same tool
Planner Poker lets you choose Fibonacci or T-shirt sizing when you create a room, so you can run a roadmap session in the morning and a sprint refinement in the afternoon without changing tools. Each room keeps its own scale, history and statistics.