T-shirt sizing for agile estimation

T-shirt sizing is an agile estimation technique where the team sizes work with labels, XS, S, M, L, XL, instead of numbers. It is the same idea as story points, comparing items by relative effort rather than guessing hours, but with a coarser, non-numeric scale that is faster to apply and easy for non-technical people to read. That makes it a good fit for early, high-level planning and for sizing a large backlog quickly. Below: how to run it, when to use it over points, how to map sizes to points, and where it breaks down.

What is t-shirt sizing?

Instead of asking "how many story points" or "how many hours", the team asks "is this a small, a medium, or a large". Each item gets a shirt-size label based on its relative effort, complexity and uncertainty combined. The labels are deliberately vague, which is the point: at an early stage you want a rough sense of size, not false precision.

Because there are only a handful of sizes and no maths involved, a stakeholder who has never estimated software can still take part. That accessibility is one of the method's main strengths.

The sizes and what they mean

There is no fixed definition, and each team calibrates its own, but a common reading is:

The useful signal is at the top end: an XL or XXL is a flag that the item needs breaking down before it can be worked on, not a number to commit to.

Why use t-shirt sizing

• Speed. A coarse scale with few choices is quick, so you can size a big backlog in one short pass.
• No false precision. Labels make it obvious you are giving a rough size, not a measurement. This matches the research on relative estimation: the value is in a shared sense of size, not an accurate per-item figure (see what story points are).
• Accessible to non-technical people. Product, design and business stakeholders can size alongside engineers, because nobody has to defend a number.
• Good for the first pass. It pairs well with other methods: size everything roughly with shirts, then use planning poker only on the items that matter.

How to run a t-shirt sizing session

1. Agree on a reference item. Pick one well-understood piece of work and call it your M. Everything else is sized by comparison to it.
2. Size silently first. Have each person assign a size on their own, so nobody anchors on the loudest voice, the same principle behind planning poker's simultaneous reveal.
3. Reveal and discuss the gaps. Where people disagree (one S, one L), let them explain. The discussion surfaces hidden work, exactly as in points-based estimation.
4. Group and move on. Settle on a size, place the item, and keep the pace. Flag any XL or XXL for splitting rather than estimating.

T-shirt sizing vs. story points

They are not rivals so much as different resolutions of the same idea. Many teams use both at different stages.

If you want to track velocity and forecast, you will eventually need numbers. T-shirt sizing is where many teams start, and story points are where they land for sprint planning. For the full menu of options, see our comparison of estimation techniques.

Mapping t-shirt sizes to story points

Teams often want to turn shirt sizes into points so they can do velocity maths. A loose mapping is fine, for example S = 2, M = 3, L = 5, XL = 8, as long as you treat it as an approximation and not a conversion table carved in stone. The moment people argue that an M is "exactly 3", you have thrown away the reason you used a vague scale in the first place. Keep the mapping rough, and re-size with points directly when you need sprint-level detail.

When t-shirt sizing falls short

• It does not give you velocity on its own. Labels do not add up. You need a numeric mapping, or a separate points pass, to forecast.
• The boundaries are subjective. One team's L is another's M. That is fine within a team, but sizes do not transfer between teams.
• It is too coarse for sprint detail. For deciding what fits in the next two weeks, the gap between an S and an M is often too wide. Switch to points for that.
• Large items hide inside a single label. An "L" can quietly contain a week of surprises. Use XL and XXL as a prompt to split, not a size to accept.

Common mistakes

• Treating a size as an exact number. The scale is deliberately vague. Precision defeats the purpose.
• Comparing sizes across teams. Calibration is per team, just like story points and velocity.
• Accepting XL and XXL as estimates. They are signals to break the item down, not sizes to plan around.
• Never moving to points. If you need to forecast sprints, shirt sizes alone will not get you there.

Frequently asked questions

What is t-shirt sizing in agile?

A relative estimation method where the team labels work XS, S, M, L, XL instead of using numbers. It sizes items by comparison, is quick to apply, and is easy for non-technical stakeholders to join.

What do the t-shirt sizes mean?

There is no universal definition, but roughly: XS is trivial, S is small and clear, M is a moderate chunk, L is large or uncertain, and XL or XXL means the item is probably too big and should be split. Each team calibrates its own boundaries.

Is t-shirt sizing better than story points?

Neither is better; they fit different stages. T-shirt sizing is faster and more accessible for early, high-level planning, while story points give the finer detail and the numbers you need for velocity and sprint planning.

How do you convert t-shirt sizes to story points?

Use a loose mapping, for example S = 2, M = 3, L = 5, XL = 8, and treat it as an approximation. If you need sprint-level accuracy, re-estimate those items directly in points rather than relying on the conversion.

When should you use t-shirt sizing?

Use it for a quick first pass on a large or early backlog, for roadmap-level sizing, and whenever non-technical stakeholders need to take part. Switch to points when you need sprint planning and velocity.

Who takes part in t-shirt sizing?

Anyone involved in the work, and often business, product and design stakeholders too, since the plain-language scale does not require technical knowledge to use.

Sources

1. Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014 (relative, expert-judgment sizing dominates agile estimation).
2. Poženel, M., Fürst, L., Vavpotič, D. & Hovelja, T. (2023). A comparison of planning poker, the bucket system and affinity estimation. International Journal of Software Engineering and Knowledge Engineering, 33(11n12) (coarser, faster methods reached similar accuracy to planning poker once teams were familiar).