One More Point

HomeBlogFibonacci vs T-Shirt Sizing: Which Estimation Scale Should Your Team Use?
Cover illustration for "Fibonacci vs T-Shirt Sizing: Which Estimation Scale Should Your Team Use?"

Fibonacci vs T-Shirt Sizing: Which Estimation Scale Should Your Team Use?

Fundamentals2 min read

Fibonacci vs T-Shirt Sizing: Which Estimation Scale Should Your Team Use?

When your team sits down for sprint planning, one of the first decisions is what scale to use for estimation. The two most common are Fibonacci numbers (1, 2, 3, 5, 8, 13, 21) and T-shirt sizes (XS, S, M, L, XL). Each has a different sweet spot.

Fibonacci Numbers

The Fibonacci sequence is the default for most scrum teams because the increasing gaps reflect a real truth about software estimation: the bigger a task, the less precisely you can size it.

Pros:

  • Fine-grained enough to distinguish a 3-point story from a 5-point one
  • Directly feeds velocity tracking (add up points per sprint)
  • Familiar to most developers who have used Jira or similar tools

Cons:

T-Shirt Sizes

T-shirt sizing trades precision for speed. It works best for high-level roadmap planning when you need rough buckets, not sprint-level detail.

Pros:

  • Faster to converge - fewer options means less debate
  • Non-engineers find them more intuitive
  • Forces teams to avoid false precision on uncertain work

Cons:

  • Can't be summed for velocity tracking without a mapping (S=2, M=5, etc.)
  • "Large" means different things to different people

How to Choose

ScenarioUse
Sprint planning with defined storiesFibonacci
Quarterly roadmap groomingT-shirt
Mixed team with non-engineersT-shirt
Teams tracking velocityFibonacci

If your team is new to estimation, start with t-shirt sizes to build the habit, then graduate to Fibonacci once everyone is comfortable with the process. For the rest of the technique family - affinity estimation, the bucket system, and where each one fits - see the agile estimation techniques guide. Whichever you pick, calibrate the scale against real stories so the values mean the same thing to everyone.

(Comparing poker against non-poker methods instead? See three-point estimation vs planning poker.)

One More Point supports both scales - pick the one that fits the meeting.

Fundamentals5 Common Planning Poker Mistakes (And How to Fix Them)Planning poker only works when the team trusts the numbers. These five mistakes quietly undermine that trust - and the fixes are simpler than you think.FundamentalsHow to Estimate Bug Fixes in Your BacklogBug fixes are notoriously hard to estimate because the scope is often unknown until you're in the code. Here's a framework for sizing them without wild guessing.FundamentalsSplitting User Stories Without Losing Estimation ValueSplitting stories to fit a sprint is easy. Splitting them so the pieces remain independently deliverable and estimable is harder. Here's how to do it right.

Ready to estimate together?

Start a free session and invite your team when you’re ready.