Definition

T-shirt sizing is a relative estimation technique where teams assign work items to broad categories like XS, S, M, L, and XL instead of specific hours or days. This method strips away the false precision of time-based estimates and forces the team to compare tasks against each other to gauge complexity and effort. It is a standard practice in agile environments because it is fast, inclusive, and shifts the focus from predicting exact dates to understanding relative scope.

Why it matters for delivery

Most planning meetings stall because teams argue over whether a task will take 4 hours or 6. That debate rarely improves accuracy. It only burns time. T-shirt sizing removes that friction. By using coarse buckets, you accept that early estimates are guesses. You trade precision for speed. This allows product managers and engineers to move through a backlog of 50 items in an hour instead of spending three days debating 10 of them.

Relative estimation also exposes hidden complexity. When a developer marks a simple login fix as XL, it signals a problem. Maybe the codebase is tangled. Maybe there is a missing dependency. The size itself becomes a conversation starter. It highlights risks before you commit to a timeline. This connects directly to how you manage your risk register. Large items often carry higher uncertainty, so flagging them early lets you plan mitigation strategies rather than reacting to surprises during sprint execution.

Furthermore, t-shirt sizing democratizes planning. Junior engineers can participate confidently because they are not asked to predict their own velocity down to the minute. They are asked to compare Task A to Task B. This builds team alignment and shared understanding of what “hard” means in your specific context. It reduces the anxiety of being wrong and encourages honest assessment of effort.

How it works in practice

The process starts with anchor items. You need a reference point for each size. For example, a Medium might be a standard feature that takes one person two days to build and test. An Extra Small is a typo fix or a config change. An Extra Large is a new integration that requires external API documentation and security review. Once anchors are set, the team sizes new items by comparing them to these known quantities.

In Anabatic, you can implement this by adding a custom property called “Size” to your Boards. Use a single-select field with options for XS, S, M, L, and XL. Color-code these options for visual clarity. Green for XS, yellow for M, red for XL. This visual cue helps stakeholders scan the board and understand workload distribution at a glance. You can also use automation rules to trigger actions based on size. For instance, if a ticket is marked XL, the automation can automatically assign it to the tech lead for review or add a “Needs Decomposition” label. This ensures large items do not slip through the cracks.

During planning sessions, use the stand up meeting format to discuss sizing. Instead of a long workshop, do a quick dot-voting exercise. Each team member privately selects a size for a ticket. Then reveal the choices. If everyone agrees, move on. If there is disagreement, discuss the outliers. The goal is not to reach consensus on the exact size but to understand why perspectives differ. Often, the discussion reveals missing requirements or technical constraints that need clarification before work begins.

A worked example with real numbers

Consider a marketing team planning a quarterly campaign. They have five tasks to size:

• Update homepage banner image
• Redesign email signup form
• Integrate new CRM data feed
• Write blog post series (5 posts)
• Fix broken link in footer

Using t-shirt sizing, the team assigns sizes based on historical anchors:

• XS: Fix broken link in footer. This is a 10-minute task. No design, no testing beyond verification.
• S: Update homepage banner image. Requires design asset creation and a quick CMS update. Takes about 2 hours.
• M: Redesign email signup form. Involves UX design, copywriting, frontend development, and A/B test setup. Takes 3 days.
• L: Write blog post series. Requires research, drafting, editing, and SEO optimization for 5 distinct posts. Takes 1 week.
• XL: Integrate new CRM data feed. Requires API documentation review, backend development, data mapping, security compliance check, and extensive QA. Takes 2 weeks.

Now map these sizes to capacity. Assume the team has 40 hours per week. If XS = 1 hour, S = 2 hours, M = 12 hours, L = 40 hours, and XL = 80 hours, you can see the load. The team can take one XL, one M, and two S tasks in a two-week sprint. This simple math prevents overcommitment. It also highlights that the CRM integration dominates the sprint. You might decide to break that XL into smaller pieces to reduce risk. This approach gives you a realistic view of lead time for each deliverable without getting bogged down in hourly estimates.

Common mistakes and how to avoid them

The most common error is treating sizes as absolute time units. If you say “Medium equals 3 days,” you defeat the purpose. Complexity varies. A medium task for a senior engineer might take 4 hours. For a junior engineer, it might take 2 days. Keep sizes relative to complexity, not clock time. Another mistake is having too many sizes. If you use XS, S, SM, M, ML, L, XL, XXL, the differences become meaningless. Stick to 5 sizes maximum. If you need more granularity, split the work into smaller tasks instead of adding size categories.

Teams also fail to update their anchors. As skills improve and tools mature, a Medium task might become an Small. Review your anchors quarterly. Adjust them if the team’s velocity changes significantly. Finally, do not use t-shirt sizing for everything. It works best for feature development and project planning. For maintenance or support tickets, use priority levels instead. Mixing estimation methods creates confusion. Use a meeting notes template to document your sizing decisions and anchors. This creates a living reference that new team members can consult to understand how the team estimates work.

How it connects to the rest of your plan

T-shirt sizing is not an isolated activity. It feeds directly into your roadmap and resource planning. In Anabatic Timeline, you can map sizes to durations for high-level forecasting. If you know an XL typically takes 2 weeks, you can block out that time on the Gantt chart. This gives stakeholders a realistic view of delivery dates without promising exact hours. It also helps in Goals setting. If a strategic objective requires five XL tasks, you know it will take months, not weeks. This prevents setting unrealistic OKRs.

Furthermore, sizing data improves your retrospectives. Track the actual time spent on tasks compared to their assigned size. If all Mediums are taking twice as long as expected, your anchors are off. Adjust them. This continuous feedback loop makes your planning more accurate over time. It turns estimation from a guessing game into a data-driven practice. By integrating sizing into your daily workflow, you create a culture of transparency and realistic expectations. You stop fighting over hours and start focusing on delivering value.

Frequently asked questions

What is t-shirt sizing in agile?

T-shirt sizing is a relative estimation technique where teams categorize work items into sizes like XS, S, M, L, and XL based on complexity and effort. It replaces precise hour estimates with broad buckets to speed up planning and reduce debate over exact timelines.

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

You do not need to convert them. T-shirt sizes serve the same purpose as story points: relative estimation. If your team prefers points, you can map XS to 1, S to 2, M to 3, L to 5, and XL to 8. The key is consistency, not the specific numbers.

When should you stop using t-shirt sizing?

Stop using t-shirt sizing when tasks are too small to differentiate or too large to estimate reliably. For very small tasks, use priority. For very large tasks, break them down into smaller pieces until they fit into your size buckets. If an item remains XL after decomposition, it likely needs further analysis.

Can t-shirt sizing improve team velocity?

Yes, by reducing planning overhead and exposing hidden complexity. When teams spend less time debating estimates and more time discussing technical challenges, they identify blockers earlier. This leads to smoother execution and more predictable delivery, which stabilizes velocity over time.