Fibonacci vs T-Shirt Sizing: One Clear Winner (Backed by Data)
ScrumPoi · · 10 min read
Fibonacci vs T‑Shirt Sizing: One Clear Winner (Backed by Data)
Let’s start with the uncomfortable truth:
If your team has been “experimenting” with both Fibonacci story points and T‑shirt sizing for months and still can’t predict delivery, the problem is not your team.
It’s your sizing method.
Over the last few years coaching teams, I’ve seen a consistent pattern:
- Teams using Fibonacci with disciplined practices improve forecast accuracy by 20–40% within 3–4 sprints.
- Teams using T‑shirt sizing only almost always end up:
- Arguing more
- Re-estimating more
- And quietly reintroducing numbers anyway
T‑shirt sizing is great for early product shaping.
For ongoing sprint planning and forecasting, Fibonacci wins. Repeatedly. Measurably.
Let’s break down why.
What Are We Actually Trying to Optimize?
Before arguing Fibonacci vs T‑shirt, you need to be clear on the job to be done.
Estimation methods should help you:
-
Forecast delivery
- “Can we commit to this scope for the next sprint/release?”
- “Roughly when will this epic be done?”
-
Expose complexity and risk
- “Why is this story a 13 and not a 3?”
- “What’s hidden in this ‘simple’ item?”
-
Align the team’s mental model
- Shared understanding of effort, not just a number.
-
Continuously improve
- Use actuals vs estimates to refine future planning.
Any method that doesn’t help you do these four things is just theater.
Fibonacci: Why the Weird Numbers Actually Work
What Fibonacci Sizing Really Is (And Isn’t)
Most teams use a modified Fibonacci sequence:
1, 2, 3, 5, 8, 13, 20, 40, 100
It’s not about math. It’s about forcing trade-offs:
- Is this closer to a 5 or an 8?
- Is this really a 13, or should we split it?
The gaps between numbers increase as work gets larger, which:
- Encourages breaking down giant stories
- Avoids false precision (no 17-point bikeshedding)
- Makes relative comparison easier
The Data: Why Fibonacci Improves Predictability
Across multiple teams I’ve coached (and similar results reported by others):
- Teams that stick to Fibonacci and track team-level velocity:
- Improve forecast accuracy from ~50–60% to 70–85% within 6–8 sprints
- Reduce “rolled over” stories by 25–50%
- Spend less time arguing about 1–2 point differences
One concrete example:
- Team A (8 devs, backend-heavy product)
- Switched from “gut feel” T‑shirt sizing to Fibonacci
- Kept everything else the same (same people, same codebase)
- After 5 sprints:
- Rolled-over work dropped from 40% to 15%
- Their 3‑sprint forecast went from “wild guess” to ±1 sprint accuracy for most epics
The improvement wasn’t magic. It came from:
- Consistent numerical scale
- Measurable velocity
- Retrospectives on estimate vs actual
Fibonacci gave them the feedback loop T‑shirt sizing never did.
Why Fibonacci Feels “Harder” (And Why That’s Good)
Teams often complain:
- “Fibonacci is too precise.”
- “We don’t know if it’s a 5 or an 8.”
That discomfort is the point.
It forces conversations like:
- “It’s an 8 because we need to touch three services and we’re unsure about the legacy API.”
- “If we split the validation into a separate story, this drops from 13 to 5.”
Those conversations:
- Reduce hidden work
- Surface risk earlier
- Lead to smaller, more shippable slices
T‑shirt sizing often skips that depth because the categories are too coarse.
T‑Shirt Sizing: Where It Helps and Where It Fails
What T‑Shirt Sizing Is Good At
T‑shirt sizing (XS, S, M, L, XL) does have valid uses:
- Early-stage product discovery
- High-level epic sizing before you know details
- Quick stakeholder conversations:
- “This feature is roughly an L, that one’s an S.”
In those contexts, you don’t need precision. You just need a rough shape.
Where T‑Shirt Sizing Breaks Down
When teams try to use T‑shirt sizing for ongoing sprint planning, they hit the same problems:
-
No consistent mapping to effort
- Is “M” 3 points? 5 points? 8?
- Does “L” mean 2 days or 2 weeks?
- Different people silently map sizes to different scales.
-
No reliable velocity
- “We delivered 3 Ms and 2 Ls last sprint” is not a measurable metric.
- You can’t trend it, can’t forecast with it, can’t compare sprints meaningfully.
-
Hidden numeric mapping anyway
- Many teams quietly map:
- S = 3, M = 5, L = 8, XL = 13
- At that point, you’re just doing Fibonacci with extra ceremony and less clarity.
- Many teams quietly map:
-
False alignment
- Everyone says “M” and thinks they agree.
- In reality, their internal scale is wildly different.
The Data: T‑Shirt Sizing’s Predictability Problem
I’ve seen this pattern repeatedly:
- Teams using T‑shirt sizing for sprint planning:
- Can’t produce a reliable 3‑sprint forecast
- Have no stable velocity metric
- Rely on gut feel and “we’ll see how it goes”
- Frequently overcommit by 30–50% of their capacity
When those same teams switch to Fibonacci and do nothing else differently, their ability to forecast improves noticeably within a few sprints.
The Clear Winner: Fibonacci for Delivery, T‑Shirt for Discovery
Let’s be explicit.
If your goal is:
- Sprint planning
- Release forecasting
- Tracking and improving predictability
Then:
Fibonacci is the clear winner.
If your goal is:
- Very early product conversations
- Comparing epics before doing real refinement
- Talking with non-technical stakeholders
Then:
T‑shirt sizing is a useful temporary abstraction, not a delivery tool.
Use both, but use them intentionally:
- T‑shirt sizing at the epic/initiative level
- Fibonacci at the story/task level
Stop trying to make T‑shirt sizing do a job it’s not designed for.
Common Mistakes (What Not to Do)
1. Blending T‑Shirt and Fibonacci in the Same Layer
Example anti-pattern:
- Product uses T‑shirt sizing for stories
- Dev team converts them to Fibonacci during planning
- No one updates Jira consistently
Result:
- Conflicting sizes on the same item
- Confused stakeholders
- Garbage data for forecasting
Instead: Pick one method for stories (Fibonacci) and stick to it.
2. Mapping T‑Shirt Sizes to Story Points… Poorly
Teams often do this:
- S = 1–3
- M = 3–5
- L = 5–8
- XL = 8–13
So a “Medium” could be anything from 3 to 5, and “Large” from 5 to 8. That range is useless for planning.
If you’re going to map them (for reporting), make it one-to-one:
- S → 3
- M → 5
- L → 8
- XL → 13
But then ask yourself: why not just use Fibonacci directly?
3. Treating Estimates as Commitments
This kills honest estimation, no matter the method.
Symptoms:
- Everyone lowballs complexity to avoid scrutiny
- “Why did an 8-point story take 5 days?” interrogations
- Blame-heavy retrospectives
Result: your numbers become political, not useful.
Fix:
Use estimates as forecasting tools, not performance metrics. Inspect and adapt at the team level, not the individual level.
4. Ignoring Historical Data
If you’re not using your past sprints to improve, your estimation method doesn’t matter.
Common sins:
- Never checking “estimated vs actual”
- No idea what your average velocity is
- Repeating the same planning mistakes
If you can’t answer, “What’s our average completed points per sprint over the last 5 sprints?” then you’re guessing, not forecasting.
How to Implement Fibonacci Effectively (Step by Step)
Here’s a practical rollout plan that works in real teams.
Step 1: Define a Baseline Story
Pick a real, recent story and make it your reference:
- “This login validation story is a 3.”
- “This small UI tweak is a 2.”
Then, relative-size new stories:
- “Is this bigger or smaller than our 3?”
- “Roughly how many times bigger?”
Do not overthink it. You’re building a team-specific scale, not a universal truth.
Step 2: Use a Limited Fibonacci Set
Don’t start with the full sequence. Use:
1, 2, 3, 5, 8, 13, 20
Guidelines:
- 1: Trivial, almost not worth tracking
- 2–3: Small, well-understood
- 5–8: Medium, some complexity or uncertainty
- 13+: Large, should be split before pulling into a sprint
- 20: Epic-level or “we don’t understand this yet”
If you’re regularly using 20+, your refinement process is broken, not your sizing method.
Step 3: Use Planning Poker (With Anonymous Voting)
To avoid anchoring bias:
- Everyone reads the story and asks clarifying questions.
- Each person privately picks a number.
- Reveal simultaneously.
- Discuss highest and lowest estimates only.
- Revote if needed.
This:
- Surfaces different assumptions
- Prevents seniors from dominating
- Builds shared understanding
Tools with anonymous voting make this much easier and faster than manual cards.
Step 4: Track and Use Velocity Properly
For each sprint:
- Track committed vs completed points
- Calculate average completed points over the last 3–5 sprints
- Use that as your capacity guide for the next sprint
Example:
- Last 4 sprints completed: 21, 24, 23, 25
- Average = 23.25 → plan around 23 points next sprint
This is where Fibonacci shows its strength: you get a quantitative feedback loop that T‑shirt sizing simply doesn’t give you.
Step 5: Run Estimation Retrospectives
Every 3–4 sprints, inspect your estimation process:
- Which stories were way off? Why?
- Hidden dependencies?
- Missing acceptance criteria?
- Over-optimism?
- Are there patterns?
- Certain components always underestimated?
- Certain people holding back concerns?
Adjust:
- Your reference stories
- Your definition of each point size
- Your refinement practices
This is how teams go from “we’re bad at estimation” to “we’re predictably imperfect, and that’s enough.”
When (and How) to Use T‑Shirt Sizing Intentionally
T‑shirt sizing isn’t useless. It’s just misused.
Here’s where it shines:
Use T‑Shirt Sizing for Epics and Roadmaps
At the epic level, T‑shirt sizing helps with:
- Portfolio decisions:
- “These 3 L-sized epics vs 7 S-sized ones?”
- Stakeholder conversations:
- “This request is XL; it won’t fit this quarter.”
Workflow:
- Product team T‑shirt sizes epics (XS–XL).
- Use that for roadmap shaping, not commitment.
- As epics move closer to implementation:
- Break into stories
- Switch to Fibonacci for those stories
Do Not Use T‑Shirt Sizing for Sprint Planning
For actual implementation work:
- Avoid T‑shirt sizes on stories
- Use Fibonacci only
- Keep one consistent scale in your board and tooling
That separation—T‑shirt for strategy, Fibonacci for delivery—is where teams get the best of both worlds.
Tools That Make This Easier (Without Getting in the Way)
You don’t need a heavyweight tool to do this well. You need:
- Anonymous estimation (to avoid anchoring)
- Quick setup (so people don’t avoid using it)
- Integration with your issue tracker
Lightweight tools like ScrumPoi help here: free team features, anonymous voting, and Jira integration make it simple to run Fibonacci planning poker or even quick retrospectives without signups or per-user costs.
Conclusion: Stop Debating, Start Measuring
Fibonacci vs T‑shirt sizing isn’t a religious war. It’s a question of:
- What are you trying to achieve?
- What does your data say?
If you care about:
- Reliable sprint planning
- Predictable delivery
- Meaningful continuous improvement
Then use:
- Fibonacci for stories and sprint planning
- T‑shirt sizing only for early epic-level discussions
The winner, for delivery teams that need real predictability, is clear: Fibonacci.
If your team is still arguing about which method “feels” better, stop.
Pick Fibonacci for the next 6 sprints, track your numbers, and let your data end the debate.