T-Shirt Sizing in Agile: How It Works, When to Use It, What to Avoid (2026)
T-shirt sizing is an agile estimation technique where the team sizes work using XS, S, M, L, and XL instead of hours or story points. It is the fastest way to get rough estimates on a backlog because everyone already knows the difference between a small and an extra large. Most teams use it for roadmap conversations, release planning, and the early stages of backlog grooming.
The method is honest about being a rough cut. It refuses to give a number that someone will later treat as a commitment. This guide walks through how t-shirt sizing actually works and when it beats story points. It also covers the pitfalls most explainers skip and a practical pattern for client-facing roadmaps.
Quick answer: what t-shirt sizing is
T-shirt sizing assigns work to one of five buckets: XS, S, M, L, and XL. Teams discuss each story for one to two minutes, agree on a size, and move on. The sizes are relative. An L is larger than an M but smaller than an XL. The team learns what those sizes mean for their own work over time. There is no fixed conversion to hours.
The technique is meant for moments when detail is thin and the goal is direction, not exact dates. Roadmaps, quarterly plans, early user-story sweeps, and pricing conversations with clients all fit. Sprint-level estimation, where the team needs precise capacity numbers, is usually a worse fit. T-shirt sizing tells you a story is roughly twice another story, not that it will close in 14 hours.
Try a sizing session, live
The board below holds five stories of varying scope. Drag each one into the size that fits. Toggle Story points to see a Fibonacci conversion and a running capacity total. Toggle Planning Poker mode to hide the sizes after you drop them, so a team can simulate a blind estimation round, then click Reveal.
Size your backlog
Drag each story into the size that fits. Add your own stories with the + button. Set a sprint capacity to see when you go over.
Drag a card from Unsized into XS, S, M, L, or XL. Use + Add to add your own.
Tap a card, then tap a column header
Two things stand out once you have used the board. First, sizing five stories takes under a minute. Second, the moment Story points is on, the room starts asking, "is L really 5 points?" That conversation is the point. Sizes are an opening move; the team's own data tells you what each size means in the next sprint.
When to use it, when not to
T-shirt sizing earns its keep in four places. Roadmaps over a quarter or longer, where the work is too vague for point estimates. Release planning, where the goal is to fit work into a release rather than commit to a sprint. Early backlog grooming, before user stories have acceptance criteria. And client-facing scoping calls, where the buyer needs a shape, not a quote.
It fails in three places. Sprint-level commitments, where the team needs to know if 40 points fits in two weeks. A bag of L sizes does not give that answer. Velocity tracking, where the team is benchmarking output across sprints and needs additive numbers. And reporting to non-technical executives who treat L as "around three weeks" and then anchor a release date on it. In the last case, the size becomes the commitment, which defeats the purpose.
Vasco Duarte started the #NoEstimates movement in 2012. He reported that when his team replaced every story-point value with "1," the forecast changed by only 8 percent. That is the warning behind any estimation method. If the team is using sizes to feel certain about a date, the sizes are not the problem. The certainty is.
T-shirt sizing vs story points vs Planning Poker
Four methods compete for the same job. The honest choice depends on what the team needs the estimate to do.
| Method | How it works | Best for | Watch out for |
|---|---|---|---|
| T-shirt sizing | Five buckets (XS to XL). The team agrees on a size per story in seconds. | Roadmaps, release plans, early grooming, client scoping calls. | Not additive. Cannot be summed into a capacity number without conversion. |
| Story points | Fibonacci numbers (1, 2, 3, 5, 8, 13) assigned per story. | Sprint-level commitments, velocity tracking, mature teams with baseline data. | Drift over time. A 3 today is not always a 3 next quarter. |
| Planning Poker | Each team member picks a value privately, then everyone reveals together. | Junior-heavy teams, any team where anchoring is a problem. | Slower. Takes 3-5 minutes per story instead of one. |
| Ideal days | Estimate in days of focused work assuming no interruptions. | Teams new to agile coming from waterfall, fixed-bid work. | Clients and managers treat ideal days as calendar days, which they are not. |
Mike Cohn, who literally wrote the book on agile estimating, puts the trade-off plainly. He calls t-shirt sizes "an OK approach to getting started with relative estimating" but warns of two severe weaknesses. They are not additive. You cannot tell a boss you will be done in three mediums, four larges, and two petites. And your view of an XL may not match mine. You may think it is 50 percent bigger than an L; I may think 25 percent. His recommendation: start with t-shirt sizes if it is easier, but put numbers under them. Use M = 5 and L = 8 as a starting map, then gradually shift to the numbers directly.
Planning Poker, invented by James Grenning in 2002 during a stalled XP planning meeting, layers on top of any of the others. The mechanism is the private vote, not the number system. Pair Planning Poker with t-shirt sizing for a team where the senior voice tends to set the size before the juniors speak. Pair it with story points for a team that is already comfortable with numbers but is anchoring on a familiar story.
Run sizing in the same place the team chats.
Rock pairs chat with a task board, so the sizing call, the stories, and the follow-up live in one space. One flat price, unlimited users.
How to run a t-shirt sizing session
The session works best as a 45-minute meeting with the team that will do the work. The product owner or account lead brings a list of stories. The team brings recent context. The five steps below cover the shape of a good session.
- Anchor with a reference story Pick one small story everyone agrees on and call it an S. Every other size in the session is relative to that anchor. Skip this step and the first story you size becomes the accidental reference, which is usually too large.
- Walk through one story at a time The product owner reads the story and any acceptance criteria. The team has two minutes to ask questions. Then everyone calls a size at once, or drops their card on the board in Planning Poker mode.
- Discuss outliers If estimates span more than two sizes (an S and an L on the same story), pause and let the highest and lowest voices explain. The conversation is the value. The second vote is almost always tighter, and the team learns where its hidden assumptions live.
- Re-size after the discussion, not before Avoid the trap of letting the loudest voice update the size before the second vote. The point of the vote is to surface the disagreement. Average the room only after every voice has been heard.
- Convert to capacity at the end, not during Once every story has a size, map the sizes to story points (S = 2, M = 3, L = 5, XL = 8 is a common starting set) and sum the points. This is the moment to compare against the team's velocity from the last few sprints.
Janaka Fernando is a product owner who has written about running sizing sessions with engineering teams. He makes the practical observation that the time savings come from the constraint. In his words, participants have to pick from a fixed set of sizes rather than guessing exact hours. The five buckets force a decision in seconds. An hours estimate invites a five-minute calculation.
T-shirt sizing for agency client roadmaps
Agencies hit a wall with story points the moment a client sees them. A non-technical buyer hears "13 points" and either pretends to understand or asks what a point is. The conversation goes sideways. T-shirt sizes survive that handoff because everyone has worn a shirt. Telling a client that their Q3 roadmap has two XLs, three Ls, and six Ms gives them a shape to react to. No tutorial needed.
The pattern that holds up across agency work: use t-shirt sizes for any artifact a client will see. Use story points internally once the work breaks down into a sprint backlog. The two systems do not need to be reconciled in public. They need to map to each other once, inside the team, so L stories on the roadmap become 5-point stories on the sprint board.
Anchor calendar expectations carefully. An L might be one to two weeks of work for a 5-person team; an XL might be two to four weeks. Say that out loud to the client. Otherwise they will quietly translate L into "I will have it next Friday" and the next conversation gets adversarial. Putting a calendar band against each size on the roadmap kills 80 percent of those conversations before they start. The caveat: scope changes shift the band.
The last pattern: retainer scoping. When a new client asks what their monthly retainer buys, t-shirt sizing answers the question without a long discovery. A typical retainer with us closes 1 XL, 2 Ls, and 3 Ms a month. That sentence is enough for the buyer to push back on the mix. If they want a second XL, they trade for two Ms. The conversation is concrete because the units are familiar.
Common pitfalls
Most teams stub their toe on the same six things. Knowing the failure modes ahead of time is most of the fix.
- Anchoring on the first card The team sizes the first story as M without discussion, and every other story becomes relative to that arbitrary M. Always anchor with a small reference story the team agrees on, not the first item on the list.
- Sizing without acceptance criteria An "add a search bar" story is an S without edge cases and an XL once you account for filters, sort order, and empty states. Force the team to name the acceptance criteria before sizing, even at one bullet.
- The loudest voice wins Junior team members match the senior estimate because they do not want to disagree in public. Planning Poker mode is the fix. Hide the sizes until everyone has dropped a card.
- Premature conversion to hours The team sizes a story as L, then immediately translates it into "about 20 hours." The relative-estimation benefit evaporates and the team is back to estimating in hours with extra steps. Convert at the end of the session, not during.
- Mid-sprint re-sizing Two days into the sprint, the team decides a story was actually an XL instead of an L. Resist. The sprint already started; logging the mistake for the next planning is more useful than re-sizing now. Re-sizing thrash kills the visibility benefit of the burndown.
- Collapsing to S, M, L only Teams drop XS and XL because they feel rare, then everything piles into M. Granularity dies. Keep all five buckets and force the conversation when nothing lands in XS.
What we recommend at Rock
Rock is not a dedicated agile tool, but most of our customers run sizing sessions inside the same workspace they use for chat. The pattern that compounds is small: keep the stories, the sizing call, and the follow-up conversations in one space. A sizing session in a separate tool that nobody opens between sprints loses 80 percent of its value to context switching.
Practical setup. Each sprint or quarter has a Rock space. The task board holds the stories with the t-shirt size in the description. Prefix the size with a single letter (S, M, L, XL) so the board sorts cleanly. The sizing call happens as a scheduled meeting with the agenda posted in the space chat. Outcomes are logged as task updates in the same space. Anyone joining the project a week later sees the sizing decisions next to the work.
For agency teams working across multiple clients, each client gets a space, and the t-shirt convention stays identical across spaces. A project lead moving between three client spaces reads the same shorthand everywhere. Consistency in the sizing language matters more than the choice between t-shirt sizes and story points. The team's brain stops translating, and the conversations get faster.
When picking between methods, default to t-shirt sizing for any artifact a client touches. Move to story points internally once the team has three or four sprints of velocity data to anchor against. Use Planning Poker any time the team has a juniors-and-seniors mix, regardless of which sizing scheme sits underneath.
Frequently asked questions
Is XL bigger than 13 story points?
There is no fixed conversion. A common starting map is XS=1, S=2, M=3, L=5, XL=8, which puts XL below 13 points. Teams that work on large epics often add XXL=13 or split anything that feels like a 13 into smaller stories before the sprint.
Can you use t-shirt sizing and story points together?
Yes, and most agency teams should. Use t-shirt sizes for roadmaps and client conversations, then convert to story points for sprint commitments. The mapping needs to be agreed once and then stay stable, otherwise the velocity numbers drift across sprints.
How do you convert t-shirt sizes to days?
Do not convert directly. Convert to story points first, then apply the team's velocity to get a sprint count, then translate sprints into calendar weeks. Direct size-to-days conversion turns the sizes into commitments and defeats the purpose of relative estimation.
When should you not use t-shirt sizing?
Skip it for sprint-level commitments where the team needs precise capacity. Skip it when a non-technical stakeholder will treat sizes as fixed delivery dates. Skip it for fixed-bid client work where the contract requires hour estimates. Stick with t-shirt sizes for vague work, roadmaps, and early-stage scoping.
T-shirt sizing or Planning Poker, which is better?
They solve different problems. T-shirt sizing is a sizing scheme. Planning Poker is a voting method that can use any scheme, including t-shirt sizes. Pair them when the team has anchoring problems or a senior-junior dynamic that biases first-vote estimates.
How long should a t-shirt sizing session take?
A 45-minute meeting handles 15 to 25 stories comfortably. If the team needs longer per story, the stories are too vague and need acceptance criteria before sizing. If the team finishes in 10 minutes, the sizes are probably not being discussed enough.
T-shirt sizing is the right opening move for any team that needs estimates fast and is honest about not knowing exact dates yet. It is not the right closing move when the team needs commitments inside a sprint. Use it where the work is vague and the audience is broad. Switch to story points and a real velocity baseline once the team is committing to specific work in specific weeks. Both methods belong in an agile team's toolkit. A sizing session that picks the right one for the moment beats any single-method shop.
