T-Shirt Sizing for Agile Estimation
T-shirt sizing replaces story points with familiar clothing sizes - XS, S, M, L, XL, XXL - trading precision for speed. It's the technique agile teams reach for when Scrum Poker would be too slow or too precise for the situation: early roadmap grooming, rooms with non-engineers, or backlogs too large to size item by item. This page covers how it works, when it beats Scrum Poker, and its real limitation. For the full technique family, see the complete agile estimation guide.
How it works
The team looks at a backlog item and picks a size from a small, fixed set - XS, S, M, L, XL, XXL - the same way estimating whether a shirt fits doesn't require knowing exact measurements. Voting can happen the same way as Scrum Poker - privately, then revealed together - or more loosely, since the categories are coarse enough that exact anchoring matters less.
The entire appeal is that coarse categories resolve faster than fine-grained numbers. Nobody spends three minutes debating whether something is a Medium or a Large the way they might debate a 5 versus an 8 - the categories are deliberately too wide to argue precisely about, which is the point, not a flaw.
When t-shirt sizing beats Scrum Poker
Roadmap-level, quarters-out estimation. A feature that's six months from being refined doesn't have enough known detail to justify a numeric estimate - any precision at that stage is false. T-shirt sizes communicate "roughly how big" without pretending to a level of accuracy the information doesn't support.
Rooms with non-engineers. Stakeholders who've never estimated software find "this is a Large" far more intuitive than "this is an 8," with no loss of the actual signal being communicated. This makes t-shirt sizing the natural choice for planning sessions that include product, design, and leadership alongside engineering.
Fast triage of a big batch. Sizing fifteen roadmap items in twenty minutes is realistic with t-shirt sizes; the same fifteen items as full Scrum Poker rounds, with discussion on each, would take considerably longer - time that isn't justified for work that's months from being built anyway.
The real limitation: it doesn't sum without a mapping
Story points are summable by design - a sprint's total points is a meaningful number because points share a common scale. T-shirt sizes don't share that property on their own: "the roadmap has 3 Larges and 5 Mediums" doesn't directly answer "how much total work is that," because Large and Medium aren't defined as multiples of each other.
Teams that need a velocity-style number from t-shirt-sized work introduce an explicit size-to-point mapping - commonly something like XS=1, S=2, M=3, L=5, XL=8, XXL=13, mirroring the Fibonacci gaps. This works, but it quietly reintroduces the precision debate t-shirt sizing was chosen to avoid: agreeing that "Large equals 5" is itself a small estimation exercise. Most teams that need this treat the mapping as a rough planning tool, not a number to defend story by story.
A worked example
A product team is grooming next quarter's roadmap: fifteen items, none refined into sprint-ready stories yet. "Redesign the authentication flow" gets XL without much debate - everyone can tell it's a big, cross-cutting change even without a detailed plan. "Add a tooltip to the settings page" gets XS just as fast. The team burns through all fifteen items in about twenty minutes, spending real discussion time only on the two or three that split opinion (is the new onboarding flow a Large or an XL?) rather than debating every item to the same depth.
Contrast that with what happens if the same team tries full Scrum Poker on all fifteen: precise numeric votes on items that are, honestly, still vague ideas - debate that feels rigorous but is actually just arguing about a decimal point of confidence nobody has yet.
T-shirt sizing vs. Fibonacci: which scale, when
| T-shirt sizing | Fibonacci (Scrum Poker) | |
|---|---|---|
| Best for | Roadmap-level, rough sizing | Sprint-ready stories |
| Speed | Fast - coarse categories resolve quickly | Slower - more precise, more discussion per item |
| Non-engineer friendly | Yes | Less so - numeric points feel arbitrary without context |
| Feeds velocity directly | No - needs a mapping | Yes - points sum natively |
| Right stage of the cone of uncertainty | Early, vague | Late, refined |
Full comparison including the underlying "cone of uncertainty" reasoning: Fibonacci vs. t-shirt sizing.
Try t-shirt sizing on a real backlog
OneMorePoint supports a t-shirt-size deck the same way it supports Fibonacci - private votes, simultaneous reveal, same mechanism, different scale. Create a free room and size a batch of roadmap items the way this page describes.