Estimation scales: Fibonacci vs T-shirt sizes

The cards in a planning poker deck are not arbitrary. Their spacing reflects how uncertainty grows with the size of the work. Here is how the two most common scales work, and when to choose each.

The Fibonacci scale

Poker Planner's Fibonacci deck:

• 0
• 1
• 2
• 3
• 5
• 8
• 13
• 20
• 40
• 100
• ∞
• ?
• ☕

In the true Fibonacci sequence each number is the sum of the two before it (1, 2, 3, 5, 8, 13, 21…). Planning poker decks use a modified version that rounds the larger values to 20, 40 and 100, because at that size the exact number stops meaning anything.

Why the gaps get bigger

People are good at saying whether one thing is roughly twice as big as another, and poor at telling a 12 from a 13. The widening gaps force a real choice: is this story more like a 5 or more like an 8? Arguing over 6 versus 7 is time a team doesn't need to spend. The gaps also make the growing uncertainty of large work visible: a 40 is a guess, and everyone knows it.

What each card usually means

• 0: already done, or trivial enough not to count.
• 1–3: small, well understood, little risk.
• 5–8: a normal story with some unknowns.
• 13: large; check whether it can be split.
• 20, 40, 100: too big for one sprint. Treat these as a signal to break the work down.
• ∞: can't be estimated as written.
• ?: I need more information.
• ☕: let's take a break.

T-shirt sizes

Poker Planner's T-shirt deck:

• XS
• S
• M
• L
• XL
• ?

T-shirt sizing trades precision for speed. With only five sizes, a team can sort a long backlog quickly, and nobody is tempted to treat the result as a commitment. Because sizes aren't numbers they can't be added up into a velocity, which is exactly why they work well before a team is ready to plan sprints.

Which should you use?

Many teams use both: T-shirt sizes to get a feel for a new epic, then Fibonacci points once the epic is split into stories ready for a sprint.

Calibrating your scale

1. Pick a small, finished story everyone remembers and agree it is a 2 (or an S).
2. Pick a larger one and agree on its size relative to the first.
3. Estimate new stories by comparing them with these references, not by counting hours.
4. Revisit the references every few months, as the team and the codebase change.