Use Fibonacci (1, 2, 3, 5, 8, 13) when a team is estimating stories for sprints and needs numbers it can add up into velocity. Use T-shirt sizing (XS to XXL) for rough, early sizing of epics or when non-technical people are voting, because nobody mistakes "Large" for a number of hours. Many teams use both: T-shirts on the roadmap, Fibonacci in sprint refinement.
Below is a comparison of the five scales teams actually use, a decision table, a T-shirt-to-points mapping, and a copy-paste estimation scale reference card you can drop into your wiki.
The five common estimation scales compared
| Scale | Values | Strengths | Weaknesses | Best for |
|---|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21, 34 | Gaps widen with size, matching rising uncertainty; widely understood; numbers add up for velocity | Upper values (21+) invite estimating things that should be split | Sprint-level story points for most software teams |
| Modified Fibonacci | 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 | Handles trivial items (0, ½) and epics (40, 100) in one deck; round numbers at the top | ½ can reintroduce false precision; 100 gets used as "huge, whatever" | Mixed backlogs with both tiny fixes and unsplit epics |
| T-shirt | XS, S, M, L, XL, XXL | No hours confusion; fast; anyone can vote | Must be mapped to numbers for velocity; mapping can become arbitrary | Roadmaps, epic sizing, mixed or non-technical groups |
| Powers of 2 | 1, 2, 4, 8, 16, 32 | Simple doubling logic; easy mental math | Fewer choices in the middle (no 3, no 5); implies a precise 2x relationship | Infrastructure or platform work where size tends to double |
| Linear | 1, 2, 3, 4, 5 (or 1 to 10) | Easiest to explain | Implies equal gaps; invites "is it a 6 or a 7?" debates; breaks down for large, uncertain work | Very uniform work like support tickets, or scoring a single factor |
Why Fibonacci-style gaps work
The core idea of a non-linear planning poker scale is that your confidence drops as items get bigger. You can tell a 1 from a 2. You cannot reliably tell a 14 from a 16, so the scale doesn't offer those choices. When the team splits between 5 and 8, the scale forces the question "which is it closer to?" instead of a fifteen-minute debate about 6.5.
You'll sometimes read that Fibonacci works because of the golden ratio or because it appears in nature. That's not really the reason. Any scale whose gaps grow roughly in proportion to size (Fibonacci, Modified Fibonacci, powers of 2) does the same job. Fibonacci is just the one most teams and tools already know.
What Modified Fibonacci changes
Modified Fibonacci, popularized through Mike Cohn's planning poker decks, keeps the low end of Fibonacci and replaces 21, 34, 55 with rounder numbers:
- 0 for work so small it isn't worth tracking separately (a copy change bundled into another story).
- ½ for tiny items a team still wants counted. Use it sparingly. If half your stories are ½ or 1, your reference story is too big.
- 20, 40, 100 signal "this is an epic, not a sprint item." The rounder numbers communicate "very rough" better than 21 or 34, which look suspiciously precise.
Fibonacci vs T-shirt sizing: when to use which
| If your situation is... | Use | Why |
|---|---|---|
| Developers estimating sprint backlog items weekly | Fibonacci | Numbers feed velocity and burndown directly |
| Backlog mixes 10-minute fixes and multi-sprint epics | Modified Fibonacci | 0/½ and 40/100 cover both ends |
| Sizing a quarterly roadmap or 30 epics in one session | T-shirt | Fast, coarse, no false precision |
| Voters include product, design, sales, or execs | T-shirt | Nobody reads "M" as hours |
| Brand-new team learning relative sizing | T-shirt first, then Fibonacci | Lower barrier, then move to numbers once references exist |
| Infra team where effort roughly doubles with scale | Powers of 2 | Matches how the work grows |
| Scoring a single factor (complexity only, risk only) | Linear 1 to 5 | Equal steps are fine for a rubric, not for total size |
| Team keeps saying "it's between M and L" | Fibonacci | More steps without inventing new sizes |
A hybrid workflow that works
- Roadmap planning: size epics with T-shirts. "Billing revamp is XL, notifications is M."
- Refinement: split anything L or larger into stories (see estimating large epics).
- Sprint-level estimation: estimate those stories in Fibonacci with planning poker.
- Check the roll-up: compare the sum of story points against the original T-shirt. If an "M" epic turned into 60 points of stories, your T-shirt mapping needs adjusting.
Mapping T-shirt sizes to story points
You'll need a mapping as soon as you want velocity or a forecast from T-shirt-sized work. A common one:
| T-shirt | Story points | Meaning |
|---|---|---|
| XS | 1 | Trivial, well understood, hours of work |
| S | 2 to 3 | Small, few unknowns |
| M | 5 | Typical story; your main reference |
| L | 8 | Large but still fits in a sprint |
| XL | 13 | Borderline; consider splitting |
| XXL | 20+ | Epic. Split before sprint planning |
Two rules keep the mapping honest:
- Map once per team, write it down, and don't negotiate it story by story. The point of T-shirts is speed; reopening the conversion every time kills that.
- Don't treat the mapping as exact. If your epics regularly come out 50% bigger once split, that's useful information about your T-shirt habits, not a reason to rescale history.
Copy-paste estimation scale reference card
A reference card is the single most useful estimation template an agile team can have. It replaces "what does an 8 mean again?" with a shared definition and a real example per value. Copy this, replace the example stories with your own completed work, and pin it where you estimate.
Fibonacci estimation template
# Estimation Scale Reference Card: [Team name]
Last calibrated: [date] Scale: Fibonacci
| Points | Meaning | Unknowns | Reference story (completed) |
|---|---|---|---|
| 1 | Trivial change, one place, obvious test | None | [e.g. Change button label on settings page] |
| 2 | Small change, one component, routine testing | None | [e.g. Add "last login" column to admin table] |
| 3 | Small feature or fix touching 2-3 areas | Minor, answerable in the story | [e.g. Email format validation on signup] |
| 5 | Typical story: new endpoint or screen, some edge cases | A few, known how to resolve | [e.g. CSV export of filtered orders] |
| 8 | Larger story, multiple components, real testing effort | Some; may need a decision mid-sprint | [e.g. Password reset via email] |
| 13 | Upper limit for a sprint; multiple systems or risky area | Significant | [e.g. Move notifications to new queue] |
| 21+ | Too big to commit. Split or spike first | Many | — |
| ? | Not enough information to vote | — | Send back to refinement |
Rules:
- Compare to reference stories, not to hours.
- Adjacent votes (5 and 8): take the higher and move on.
- Votes two or more steps apart: lowest voter explains first, then revote.
- Anything 13+ is discussed for splitting before sprint planning.
T-shirt sizing template
# T-Shirt Sizing Reference Card: [Team name]
| Size | Points (for velocity) | Meaning | Reference epic/story |
|---|---|---|---|
| XS | 1 | Hours of work, no unknowns | [example] |
| S | 3 | A day or two of team effort, clear path | [example] |
| M | 5 | Typical story | [example] |
| L | 8 | Big but fits in a sprint | [example] |
| XL | 13 | Probably needs splitting | [example] |
| XXL | 20+ | Epic. Must split before sprint planning | [example] |
Tips for filling in the card
- Use real, finished stories. Hypothetical examples drift. Real ones can be re-checked.
- Pick references that went roughly as expected. The story that exploded because of a vendor outage is a bad reference.
- Revisit quarterly. If your "5" reference now feels like a 3 because the team knows the codebase better, update it deliberately. Calibrating story points covers how.
- One card per team. If several teams need comparable numbers, see standardizing estimation across an enterprise before forcing one card on everyone.
Should you build a custom scale?
Usually not. Teams reach for custom scales (dog breeds, 1-3-7-12, decimal steps) when the real problem is missing reference stories or stories that are too big. Before inventing a scale, check:
| Symptom | Likely real cause | Fix before changing scale |
|---|---|---|
| Votes regularly span 3 to 13 | Story not understood, or different scope in people's heads | Better refinement; discuss outliers |
| Most stories land on the same one or two values | Reference story too small or too large | Re-pick references |
| "None of these numbers feel right" | No shared meaning per value | Build the reference card above |
| Long 5-vs-8 debates | Treating adjacent values as meaningfully different | Rule: adjacent = take the higher |
| Want 6, 7, 1.5, 2.5 | Thinking in hours | Re-anchor on references; see story points vs hours |
If you've fixed those and a standard scale still doesn't fit, follow a few design rules:
- Keep 5 to 9 values. More options means more debate.
- Use a clear pattern. Doubling or Fibonacci-style growth is easy to internalize. Irregular gaps like 1, 3, 7, 12 are not.
- No decimals in the middle of the scale. If you need 2.5, you're estimating hours.
- Test it on 10 to 15 completed stories before switching. If discussion isn't faster, don't switch.
- Reset velocity. Don't convert old velocity to the new scale; track three sprints fresh.
Playful scales (animals, fruit) can be fun, but they have to be mapped to numbers for any forecasting, and new hires need the mapping explained. That cost is rarely worth it.
Running planning poker with these scales
Alignlee's free planning poker offers three decks: Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?), Modified Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?), and T-shirt (XS to XXL, ?). It does not support custom decks, so if you settle on powers of 2 or a linear scale you'll need physical cards or another tool. For a deeper look at the Fibonacci deck specifically, see the Fibonacci estimation page.
Common mistakes with any scale
Inventing in-between sizes. "It's a Medium-Large." Pick one. If the team can't, the story isn't understood well enough yet.
Averaging spread votes. A 3 and a 13 don't make an 8. They mean two people pictured different work.
Switching scales mid-release. Velocity from the old scale doesn't carry over. If you switch, re-estimate your reference stories in the new scale and accept a few sprints of noisy forecasts.
Letting big numbers into sprints. 21, 40, and 100 exist on decks to say "too big," not to be committed.
FAQ
What is the difference between Fibonacci and T-shirt sizing?
Fibonacci uses numbers (1, 2, 3, 5, 8, 13) that can be summed into velocity, which makes it the usual choice for sprint-level story points. T-shirt sizing uses XS to XXL, which is faster and less likely to be confused with hours, so it suits roadmap and epic sizing. To forecast from T-shirt sizes you need a mapping to numbers.
What is modified Fibonacci in agile?
Modified Fibonacci is 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. It adds 0 and ½ for trivial items and replaces 21, 34, 55 with 20, 40, 100 so that large values read as deliberately rough. It's the most common deck for teams whose backlog includes both tiny fixes and unsplit epics.
What is the best planning poker scale?
For most software teams, Fibonacci or Modified Fibonacci. Both keep gaps wide as size grows, which stops pointless precision debates. T-shirt sizing is better for early, rough estimates or when non-technical people are voting.
Is there a Fibonacci estimation template I can use?
Yes. The reference card above is a copy-paste markdown template: one row per Fibonacci value with a plain-language meaning, the level of unknowns, and a slot for a real completed story. Fill in your own examples and recalibrate it each quarter.
How do you convert T-shirt sizes to story points?
A common mapping is XS = 1, S = 2 to 3, M = 5, L = 8, XL = 13, XXL = 20 or more (split it). Agree on the mapping once per team and write it down. Check it against reality by comparing T-shirt-sized epics with the total points of their stories after splitting.