# Fibonacci vs T-Shirt Sizing for Agile Estimation By kkrawczyk · Published 2026-07-05 · Updated 2026-07-05 https://pokerbutforplanning.com/guide/fibonacci-vs-tshirt-sizing > **TL;DR — Key takeaways** > > - Use the Fibonacci scale (1, 2, 3, 5, 8, 13…) when you need numeric story points for velocity tracking and sprint forecasting. > - Use t-shirt sizing (XS–XXL) for rough, fast sizing — roadmaps, portfolio planning, and conversations with non-technical stakeholders. > - Most Scrum teams settle on the modified Fibonacci sequence (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) because the rounded large numbers are easier to work with. > - Both scales exist for the same reason: uncertainty grows with size, so fine-grained precision at the large end is fake precision. > - You can start with one scale and switch later — the scale matters far less than estimating consistently. Fibonacci and t-shirt sizing are the two most common scales agile teams use to estimate work, and the practical difference is simple: Fibonacci gives you numbers you can add up and track, while t-shirt sizes give you fast, low-pressure buckets that resist being abused as commitments. Which one fits depends on what you need the estimates *for*. This guide explains each scale, compares them head-to-head, and ends with a decision guide you can apply in your next [planning poker](/guide/planning-poker) session. ## What is the Fibonacci scale in agile estimation? The Fibonacci scale is the sequence 1, 2, 3, 5, 8, 13, 21 — each number the sum of the previous two — used as the allowed values for story-point estimates. Teams use it because the growing gaps between numbers mirror how estimation uncertainty actually behaves: it grows with size. You can meaningfully argue whether a story is a 2 or a 3. You cannot meaningfully argue whether it's a 19 or a 21 — at that size, nobody knows enough to make the distinction. The Fibonacci sequence bakes that honesty into the deck by refusing to offer choices it knows are noise. Weber's law from psychophysics makes the same point: humans perceive differences in *relative* terms, so distinguishable estimation buckets should grow roughly geometrically. The numeric output is the Fibonacci scale's superpower. Points can be summed per sprint, which gives you velocity, which gives you forecasting — "we complete about 30 points a sprint, and this epic is roughly 120 points, so it's about four sprints of work." If you want that arithmetic, you need numbers. Our guide to [story points](/guide/story-points-explained) covers how velocity emerges from consistent point estimates. ## What is modified Fibonacci? Modified Fibonacci is the sequence 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 — the standard Fibonacci run at the small end, with rounded numbers replacing 21, 34, 55, and 89 at the large end. It's the most popular planning poker deck in practice, and the one most physical card decks print. The changes from pure Fibonacci are all pragmatic: - **0** exists for trivially small work — a config flag flip, a one-line copy change. - **½** exists for "real but tiny" stories that don't deserve a full point. - **20, 40, 100** replace 21, 34, 55, 89 because rounded numbers signal what large estimates really are: rough magnitude, not measurement. "40" reads as "roughly forty-ish"; "34" reads as false precision. The jump from 13 to 20 also patches a practical annoyance in pure Fibonacci: teams that felt a story was "more than 13 but nowhere near 21" kept wanting a middle option. [Our tool](/) supports the modified Fibonacci deck out of the box. ## What is t-shirt sizing? T-shirt sizing estimates work using clothing sizes — XS, S, M, L, XL, XXL — instead of numbers. It trades arithmetic for speed and psychological safety, and it shines in three situations: - **Roadmap and portfolio estimation.** When you're sizing epics and initiatives months out, "L" is an honest answer and "21 points" is theater. T-shirt sizes force bucket thinking and prevent anyone from doing fake math on quarter-long horizons. - **Non-technical stakeholders.** Everyone intuitively understands that an XL is much bigger than an S. Nobody asks whether an XL is exactly four times an S — but they *will* ask that about 8 points versus 2. - **New or estimation-averse teams.** Sizes feel like opinions; numbers feel like commitments. Teams that have been burned by "you said 5 points, why did it take a week?" often re-learn estimation more comfortably with sizes. The cost is that you can't sum sizes into velocity without converting them to numbers anyway — at which point you've rebuilt Fibonacci with extra steps. ## Fibonacci vs t-shirt sizing: head-to-head | Dimension | Fibonacci / modified Fibonacci | T-shirt sizing | |-----------|-------------------------------|----------------| | Output | Numeric story points | Size buckets (XS–XXL) | | Velocity tracking | Yes — points sum naturally | No — needs conversion first | | Granularity | Fine at the small end, honest at the large end | Coarse everywhere | | Speed of estimation | Moderate — invites discussion of adjacent values | Fast — fewer, wider buckets | | Stakeholder friendliness | Numbers invite misreading as time | Sizes resist being treated as commitments | | Best scope | Sprint-level user stories | Epics, roadmaps, portfolio planning | | Risk | False precision if the team over-debates 5 vs 8 | Bucket edges get fuzzy ("large medium"?) | ## What about powers of two? Powers of two — 1, 2, 4, 8, 16, 32, 64 — is a niche but coherent alternative: every step is exactly a doubling, so "this story is an 8, that one's a 4" literally means "twice the effort." Teams that like unambiguous doubling semantics choose it over Fibonacci, at the cost of slightly coarser granularity in the 3-to-5 range where many stories actually land. [Our tool](/) supports a powers-of-two deck if your team prefers it. ## How should your team choose? Pick the scale based on what you need the estimates for — the decision usually takes one conversation: - **You track velocity and forecast sprints** → modified Fibonacci. The numeric output feeds directly into sprint math, and it's what most tooling and most hires already know. - **You're sizing a roadmap or talking to executives** → t-shirt sizes. Rough buckets communicate honestly at that horizon and can't be abused as delivery dates. - **You want doubling semantics and numeric output** → powers of two. - **You're a brand-new team** → start with modified Fibonacci anyway. It's the ecosystem default, and switching later is cheap: scales are conventions, not contracts. Whichever you choose, run the actual estimation with [planning poker](/guide/planning-poker) — simultaneous reveal matters more than the numbers on the cards. And if your team spans time zones, both scales work fine [asynchronously](/guide/async-planning-poker). ## Frequently asked questions ### Can I mix Fibonacci and t-shirt sizing on the same team? Yes, as long as each scale has its own scope. A common and healthy pattern is t-shirt sizes for epics at the roadmap level and Fibonacci points for the sprint-level stories inside them. What causes trouble is mixing scales at the *same* level — estimating half the backlog in points and half in sizes makes velocity meaningless. ### Why does the Fibonacci scale skip numbers? The gaps are the feature. Estimation uncertainty grows with size, so offering a choice between 8 and 9 would imply a precision nobody has. By skipping from 8 to 13, the scale forces estimators to make only distinctions they can actually defend, which speeds up consensus and keeps large estimates honest. ### What estimation scale should a new team start with? Start with modified Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). It is the de facto industry default, every planning poker tool supports it, and new team members will already know it. If sprint-level velocity tracking turns out not to matter for your context, moving to t-shirt sizes later costs almost nothing. ### Do story points in Fibonacci correspond to hours or days? No. A 5-point story is not five hours, five days, or any fixed duration — it's roughly the effort of other 5-point stories the team has done, and mapping points to time defeats the purpose of relative estimation. Duration emerges statistically from velocity instead; our [story points guide](/guide/story-points-explained) explains why the indirection is worth it.