T-Shirt Sizing: Agile Estimation Made Simple

Ask a team what a T-shirt size actually means, and sooner or later someone will try to do math with it. "We shipped two Smalls and a Medium last sprint, so next sprint we should manage a Large." That sentence sounds reasonable. It's also nonsense, and figuring out why is the fastest way to understand what T-shirt sizing is actually for.

T-shirt sizing puts work on an ordinal scale: XS, S, M, L, XL, and sometimes XXL. Ordinal means the labels have an order (an XL is bigger than an L) but not a distance you can add, subtract, or average. Two Mediums are not one Large. A team that treats the labels as numbers loses the one property that makes the technique honest in the first place: it never claims more precision than the team actually has.

Key Facts

• The Scrum Guide deliberately does not prescribe an estimation unit. It says only that "the Developers who will be doing the work are responsible for the sizing," leaving story points, hours, or T-shirt sizes entirely up to the team.
• Mike Cohn's core critique of T-shirt sizes is that they aren't additive: "You cannot tell a boss you'll be done in 3 mediums, 4 larges, and 2 petites" (Mountain Goat Software).
• For sizing a large, previously unestimated backlog fast, Scrum.org recommends silent affinity grouping: "Affinity mapping in silence gives good enough results quite fast."
• Not everyone agrees estimation is worth the meeting time at all. The #NoEstimates line of thought, associated with Woody Zuill, asks teams to question "how do we know estimates are helping?" rather than offering a better number.

What T-shirt sizing is, and why ordinal matters

T-shirt sizing is a relative estimation technique. Instead of asking "how many hours will this take," the team asks "is this closer to a Small or a Large, compared to work we've already sized?" The output is a label from a small, fixed set: Extra Small, Small, Medium, Large, Extra Large, and occasionally Extra Extra Large for the rare item that's bigger than anything else on the list.

The word that matters most in that description is "ordinal." An ordinal scale tells you the order of things without telling you the distance between them, the way race results tell you who beat whom without telling you by how much. You know an XL is bigger than a Medium. You do not know it's exactly four times bigger, or twice as uncertain, because the scale was never built to support that kind of arithmetic.

That's a feature, not a limitation. Almost every failure mode in this technique traces back to a team doing arithmetic on the labels anyway: averaging sizes into a velocity number, converting a size into a delivery date, or comparing one team's Large against another team's Large as if the word meant the same thing in both rooms. Keep the ordinal property in view and the technique stays useful. Lose it and it quietly turns into a worse version of story points.

The coarseness is deliberate for a second reason: it defuses the false precision that creeps into hour-based estimates. When someone says a task is "12 hours," that number carries an unearned authority, even though it usually means "if nothing goes wrong, and nobody interrupts me." A Medium doesn't pretend to that certainty, and it travels better outside the team: a VP or a customer who has never sat in a sprint planning meeting instantly understands that Small beats Large, without anyone explaining what a 5 means on a Fibonacci scale.

How to run a T-shirt sizing session

A T-shirt sizing session works best when it moves fast and resists the urge to litigate every item. The steps below hold whether you're sizing five roadmap items or fifty backlog candidates in one sitting.

The anchor step deserves the most attention, since it's the one teams skip when they're in a hurry. Without a shared Small to point at, "is this a Small or a Medium" becomes a debate about vibes. With one, it becomes a genuine comparison a team can actually answer: is this more or less work than what we already agreed was a Small?

Silent sizing scales the technique to backlogs that would otherwise take hours. Each person (or the whole group together) places items along a spectrum from smallest to largest without narrating their reasoning as they go. Scrum.org's guidance on estimating large backlogs leans on exactly this instinct, describing quiet, comparison-based grouping as a way to get "good enough results quite fast" instead of grinding through each item individually. Both approaches trade item-by-item precision for speed, and both depend on the team having enough shared context to place things by comparison rather than debate.

The last step, stopping at convergence, is where the discipline actually lives. A ten-minute argument over Medium versus Large produces almost no additional information, since the scale was never built to reward that level of precision. If a team can't agree after one round of discussion, that's usually a sign the item itself is unclear, not that the group needs to argue longer.

A size definition table

Most teams that adopt T-shirt sizing benefit from writing down what each size actually means for them, once, and referring back to it instead of relitigating the definition every session.

Notice that the "what to do next" column does real work: a size is a routing decision, not just a label. Small items are close to ready; Large and Extra Large items are a signal to split before anyone plans around them in detail. That keeps T-shirt sizing connected to action instead of a label sitting in a spreadsheet column forever.

Converting T-shirt sizes into something plannable

At some point, a stakeholder wants more than "this is a Medium." They want a rough sense of when it might ship, or how much of the team's capacity it represents. Two honest approaches exist for bridging that gap, and one dishonest one to avoid.

The point-mapping hybrid. Many teams put a rough number under each size, mostly so the numbers, not the labels, carry the arithmetic. Planning poker already documents a common version: a hybrid deck of XS=1, S=2, M=3, L=5, XL=8, lining T-shirt labels up against a modified Fibonacci scale. Other teams use a different ladder, for instance Medium=5 and Large=10, doubling as size increases. Either works. What matters is picking one mapping and using it consistently: it's a convenience for talking about size, not a universal conversion table across teams.

The range-per-size approach. Instead of mapping a size to a single number, map it to a range: a Small might mean "half a day to two days," a Medium "three days to a week," a Large "one to three weeks." This keeps the honesty of the ordinal scale intact while giving planners something they can use for rough scheduling.

Whichever approach you pick, the warning is the same: a range is not a commitment. The moment a Medium's "three days to a week" turns into a promised delivery date on a client-facing roadmap, the estimate is doing a job it was never built for. Ranges communicate uncertainty; dates communicate certainty. Confusing the two turns a coarse, honest estimation method into a source of broken promises nobody remembers agreeing to.

T-shirt sizing vs story points vs planning poker vs three-point estimation vs no estimates

None of these techniques are competitors in the sense that only one is "correct." Each fits a different horizon and a different amount of certainty about the work.

Read across the "best horizon" column and the pattern matches what story points already describes: T-shirt sizing belongs furthest from execution, where a wrong estimate costs a prioritization call, not a broken sprint commitment. Planning poker and story points belong closest to execution, where the team is about to commit real capacity. Three-point estimation sits with scheduled, dependency-heavy work, usually outside a pure Scrum context. The no-estimates approach belongs to teams whose backlog is granular and stable enough that history predicts better than anyone's judgment on a single item, covered in more depth below.

Sizing at different altitudes

T-shirt sizing isn't one technique used the same way everywhere. What changes is the altitude: how far the item sits from the team that will actually build it.

At the top of that table, T-shirt sizes are doing exactly the job they're built for. The epics vs features vs user stories hierarchy already makes this point directly: epics are estimated in T-shirt sizes or rough sprint counts, and using story points at the epic level creates false precision. An epic that's still a paragraph of intent, not a set of defined stories, doesn't have the detail story points require to mean anything.

Quarterly planning and intake sit in similar territory. The goal there isn't an accurate forecast, it's a fast enough signal to decide what deserves a closer look next. A Large flagged during intake tells the Product Owner "don't promise this quickly," which is genuinely useful information even without a number attached.

The bottom row is where things go wrong most often: sizing a sprint-ready story in T-shirts is usually a step backward, not forward. By the time a story is one or two sprints out, story points already documents the expected shift: convert T-shirt sizes to points once an item is close enough to be worked. That's also the point where the team should have enough clarity to decompose the work into something closer to a work breakdown structure or, for execution-level tracking, an individual work package with real line items. T-shirt sizes exist for when that decomposition doesn't exist yet; once it does, going back to a coarse label throws away information the team already earned.

Beyond software

T-shirt sizing has nothing specific to code in it. It's a comparison technique, and any team choosing between more work than it has time for can use it.

Marketing. A campaign backlog full of "refresh the homepage hero," "launch a paid social test," and "rebuild the lead-scoring model" is impossible to compare on hours alone, since a designer's hour and a data analyst's hour aren't interchangeable. T-shirt sizes let a marketing lead rank a quarter's worth of campaign ideas by rough effort without pretending to a precision the team doesn't have.

Operations. Ops requests (a new vendor onboarding, a policy update, a tooling migration) vary wildly in scope and rarely map cleanly to a single unit of work. A Large ops request signals "this needs its own project plan," while a Small one can probably be handled inside someone's existing workload.

Professional services. Scoping a client engagement often starts with T-shirt-sized modules before a detailed statement of work exists. "Discovery is a Small, migration is a Large, training is a Medium" gives a proposal team a rough shape to price against before committing to exact hours.

Hiring pipelines. Recruiting teams sometimes size open requisitions this way: a Small role has a deep, ready talent pool and a clear job description; a Large role is a brand-new title with a thin market and an unclear internal definition of success. Sizing the requisition helps a recruiting team decide where to spend the most search effort first.

Here's a worked example from a marketing team planning a product launch quarter, using the exact size definitions from the table above.

Reading down that list, the marketing lead doesn't need a story-point velocity to see the obvious sequencing risk: the rebrand and the lead-scoring rebuild are the two items that need to start earliest and get broken down soonest, because everything else on the list depends on knowing roughly how much of the quarter they'll consume.

Failure modes

Most T-shirt sizing failures trace back to one root cause: someone doing arithmetic on an ordinal label. The specific ways it shows up are worth naming so a team can catch them early.

The cross-team comparison failure deserves a second look, since it causes the most damage quietly. Two teams reporting "we shipped three Larges this quarter" sounds comparable. It isn't, for the same reason a 50-point sprint from one Scrum team doesn't mean that team is faster than a 30-point sprint from another: both are internally calibrated scales with no shared unit behind them. The moment a size or a point total crosses a team boundary and gets treated as equivalent, it stops being useful and starts being misleading.

The limits of relative estimation

It's worth being honest about something most estimation content glosses over: there is very little rigorous, independently verified data showing that any one relative estimation technique produces more accurate forecasts than another. Claims that a method makes teams some fixed percentage more accurate circulate constantly, and most trace back to nothing verifiable. The honest position is that T-shirt sizing, story points, and planning poker are all judgment-based techniques whose value comes from making assumptions visible and keeping conversations fast, not from a proven accuracy advantage over each other.

That honesty opens the door to a real counter-argument that deserves a fair hearing. The line of thinking that gathered around the hashtag #NoEstimates, most associated with Woody Zuill, questions whether spending meeting time producing an estimate is worth the cost at all. Agile Alliance, which hosts Zuill's talk on the subject, frames his argument as a set of questions rather than a replacement technique: "How do we know estimates are helping? Can we prove estimates are helping?" The practical alternative is forecasting from throughput: track how many small, similarly sized items a team actually finishes over recent history, and project forward from that rate instead of judging the size of work still ahead.

That approach genuinely works for teams with a steady stream of small, comparably scoped items and enough history to trust the throughput number. It works less well when a backlog swings wildly in size and type, since throughput forecasting assumes the recent past looks enough like the near future to be predictive. Most organizations land somewhere in between: they keep a lightweight estimation habit for the judgment it forces, the conversation about scope, not the number it produces, while treating the resulting figure with appropriate humility. T-shirt sizing fits that middle ground well, precisely because its coarseness makes it hard to over-trust.

Related reading

• Story Points: How to Estimate Agile Work
• Planning Poker: How Agile Teams Estimate Effort
• Epics vs Features vs User Stories Explained
• Three-Point Estimation (PERT): Formula and Examples
• Velocity in Agile: How to Measure Team Throughput
• Sprint Planning: How to Run an Effective Sprint Planning Meeting
• Product Backlog: What It Is and How to Manage One
• Backlog Refinement
• Capacity Planning
• Work Breakdown Structure

T-shirt sizing earns its place in an estimation toolkit by staying deliberately coarse. The moment a team starts treating XS through XL as numbers in disguise, whether by averaging them into a velocity figure, comparing them across teams, or reading a range back as a promised date, the technique stops doing the one job it was built for. Keep the sizes ordinal, keep the session fast, and convert to something more precise only once the work is close enough to deserve it.