T-Shirt Sizing for Agile Teams

T-Shirt Sizing is a relative estimation technique used by agile teams to quickly size work items — typically epics, features, or user stories — using familiar clothing size labels rather than numeric point values. Instead of debating whether something is a 5 or an 8, teams ask a simpler question: is this Small, Medium, or Large?

The method is rooted in a fundamental truth about human estimation: people are far better at comparing things relative to one another than they are at predicting absolute durations. Asking someone how long a feature will take in hours or days triggers a cascade of uncertain assumptions. Asking them whether it is bigger or smaller than a reference story they have already completed is a much more natural cognitive task.

T-Shirt Sizing is most commonly used at higher levels of the product backlog — for epics and features that are not yet ready for detailed sprint-level estimation. It allows product managers and teams to make rough trade-off decisions about what to include in a roadmap without investing hours of refinement on work that may never be prioritised.

The technique also works well with non-technical stakeholders. Business owners, product owners, and even customers can participate meaningfully in a T-Shirt Sizing session without needing to understand Fibonacci sequences, velocity calculations, or technical complexity. The language of XS through XXL is immediately accessible to anyone.

T-Shirt Sizing and Fibonacci-based Planning Poker are both relative estimation techniques, but they serve different purposes at different stages of the backlog lifecycle.

Use T-Shirt Sizing when:

• Estimating epics and features that are too large for a single sprint
• Running a roadmap planning session where approximate sizing is sufficient
• Working with stakeholders who are unfamiliar with story points
• You need to size a large backlog quickly to identify relative priorities
• The work is exploratory and the scope is not yet well-defined

Use Fibonacci / Planning Poker when:

• Estimating user stories at the sprint level where precision influences commitment
• The team is tracking velocity and using points for capacity planning
• Stories are refined enough that the team can meaningfully discuss complexity
• You want to leverage the Fibonacci scale's natural representation of estimation uncertainty
• The conversation around disagreement in estimates is itself valuable

Many teams use both techniques at different levels: T-Shirt Sizing to size epics and features during quarterly or PI planning, and Planning Poker to estimate individual stories during sprint refinement. The two complement each other naturally.

If your team tracks velocity using story points, you will eventually need to convert T-Shirt sizes into numeric values for sprint planning and capacity forecasting. The mapping is not universal — it should reflect your team's own experience — but common conventions exist.

Keep the sizing independent of the person doing the work. T-Shirt sizes should reflect the complexity and effort of the work itself, not who is available to do it. If a task is only Small because your most senior engineer will handle it, you are conflating capacity planning with complexity estimation.

Revisit your reference stories regularly. As a team's understanding evolves and the codebase matures, what was once a Large item may become Medium as the team builds institutional knowledge. Recalibrating your reference stories at the start of each PI or quarter keeps your estimates meaningful.

Do not over-deliberate. The value of T-Shirt Sizing comes from its speed. If you find every session devolving into long architectural debates, introduce a time box per item. Set a timer, reveal votes, have one short discussion round, and commit to a size. Accept that some estimates will be wrong — that is the nature of estimation, and it is fine.

Use the technique to surface unknowns. When a team cannot agree on a size — one person says Small, another says XL — that disagreement is informative. It often reveals that participants have very different mental models of the scope or approach. Surfacing this early is far better than discovering it mid-sprint.

Document your sizing decisions with the reasoning, not just the output. A story marked as Large with a note explaining "uncertain data migration path" is far more useful to future team members than a bare size label with no context.