T-Shirt Sizing in Agile: Complete Guide to Relative Estimation

T-shirt sizing is an Agile estimation technique that uses clothing sizes - XS, S, M, L, XL, XXL - instead of numbers to estimate the relative effort of work items. It's the fastest way to size a large backlog without getting bogged down in false precision, and it's often the first estimation technique new Agile teams learn.

Why clothing sizes? Because everyone immediately understands the difference between a Small and an Extra Large. You don't need to explain what a "5" means on a Fibonacci scale or debate whether something is a 6 or a 7. A T-shirt is a T-shirt. That intuitive simplicity is exactly what makes this technique so effective for Sprint Planning, roadmap sizing, and cross-functional conversations where not everyone speaks the language of story points.

This guide covers when to use T-shirt sizing (and when not to), the step-by-step process, how to convert sizes to numeric values, common mistakes, and how it compares to Planning Poker and other techniques.

Quick Answer: T-Shirt Sizing at a Glance

Aspect	Details
What It Is	Relative estimation using clothing sizes (XS, S, M, L, XL, XXL)
Best For	Roadmap planning, large backlogs, new Agile teams, cross-functional groups
Speed	30-60 seconds per item (vs 2-5 min for Planning Poker)
Accuracy	Moderate - good for relative comparison, not precise capacity planning
Who Participates	Developers, and optionally stakeholders for roadmap-level sizing
When to Use	Early planning stages, when detail is thin and direction matters more than dates
Typical Scale	XS, S, M, L, XL (some teams add XXL or XXS)
Key Advantage	No learning curve - everyone understands T-shirt sizes immediately

What is T-Shirt Sizing?

T-shirt sizing is a relative estimation method where teams assign clothing sizes - typically XS, S, M, L, XL - to Product Backlog items based on their relative complexity, effort, and uncertainty. Instead of asking "how many story points is this?" the team asks "is this a Small or a Large?"

The technique works because it deliberately avoids numeric precision. When someone says "this is a Medium," nobody tries to calculate hours or days. The conversation stays focused on relative comparison: "Is building the password reset feature bigger or smaller than the email notification feature we already sized?"

Why Clothing Sizes Work

Three psychological principles make T-shirt sizing effective:

1. Universal Understanding Everyone has worn a T-shirt. The concept of Small, Medium, and Large requires zero explanation. Contrast this with story points, where teams spend entire sessions debating "what does a 5 mean?" T-shirt sizes eliminate that onboarding friction.

2. Natural Buckets Having only 5-6 categories forces quick decisions. You can't agonize over whether something is a "6.5 vs 7" - it's either a Medium or a Large. This constraint speeds up estimation dramatically.

3. Reduced Anchoring Words carry less numeric baggage than numbers. When someone says "Large," it's harder for others to anchor to a specific numeric value than when someone says "8 points."

T-Shirt Sizing vs Story Points

Aspect	T-Shirt Sizing	Story Points (Fibonacci)
Learning Curve	None - instant understanding	Medium - takes 3-5 sprints to calibrate
Speed Per Item	30-60 seconds	2-5 minutes
Precision	Low (5-6 buckets)	Moderate (10+ values)
Velocity Tracking	Requires conversion	Direct tracking
Best For	Roadmaps, large backlogs, new teams	Sprint planning, capacity forecasting
Stakeholder Friendly	Very - non-technical people get it	Less - "what's an 8?"
Numeric Forecasting	Not directly	Yes - velocity-based

Key insight: T-shirt sizing and story points aren't competitors - they're complements. Many teams use T-shirt sizing for high-level roadmap estimation and then convert to story points when work enters sprint planning.

The T-Shirt Sizing Process: Step by Step

Step 1: Define Your Scale

Before your first session, agree on what each size means for your team. There's no universal standard - what matters is consistency within your team.

A typical 5-point scale:

Size	Meaning	Example
XS	Trivial change, minimal effort	Fix a typo, update a config value
S	Small, well-understood task	Add a button, simple form field
M	Medium complexity, clear approach	New API endpoint with validation
L	Large, multiple components involved	Full feature with UI + backend + tests
XL	Very large, significant unknowns	Multi-system integration, new architecture

Some teams add XXL ("too big, must be broken down") or XXS ("already done, just need to verify").

Step 2: Establish Reference Stories

Pick one completed work item for each size. These become your calibration anchors.

• XS: "That CSS color change we did last sprint"
• S: "The email validation we added to the signup form"
• M: "The user profile page with avatar upload"
• L: "The payment integration with Stripe"
• XL: "The real-time notification system we built"

Write these on a wall or shared document. Reference them during every sizing session.

Step 3: Present the Work Item

The Product Owner describes the user story or feature briefly:

• What does it do?
• Who is it for?
• Any known constraints or dependencies?

Keep it to 1-2 minutes. T-shirt sizing works because it's fast - don't turn it into a requirements review.

Step 4: Size Independently

Each team member privately selects a size. Methods include:

• Physical cards with sizes printed on them
• Fingers (1 = XS, 2 = S, 3 = M, 4 = L, 5 = XL)
• Digital tools (Miro boards, Planning Poker apps with T-shirt options)

The key: everyone reveals simultaneously, just like Planning Poker. This prevents anchoring.

Step 5: Reveal and Discuss

If everyone agrees (or is within one size), record the size and move on.

If there's a spread (say, one S and one XL), have the outliers explain:

• "I said S because we built something almost identical last sprint"
• "I said XL because this touches the payment system, and compliance review alone is a week"

Usually one round of discussion resolves the gap. If not, go with the larger size - it's safer, and you can always split later.

Step 6: Record and Move On

Write the T-shirt size on the story card or in your backlog tool. Don't spend more than 60-90 seconds per item. The whole point is speed.

For large backlogs (50+ items): Use the affinity estimation variant. Instead of discussing each item, sort all items into size columns silently, then discuss only the items team members disagree on.

Defining Your T-Shirt Sizes

The most common question teams ask: "What exactly does each size mean?" Here are three approaches.

Approach 1: Effort-Based Definition

Size	Approximate Effort	Team Members Involved
XS	Under half a day	1 person
S	Half a day to 1 day	1 person
M	1-3 days	1-2 people
L	3-5 days	2-3 people
XL	1-2 weeks	Multiple people
XXL	More than 2 weeks - split it	Full team

Approach 2: Complexity-Based Definition

Size	Complexity Characteristics
XS	Known solution, no dependencies, no unknowns
S	Known solution, minimal dependencies
M	Mostly known solution, some dependencies or unknowns
L	Partial unknowns, multiple dependencies, cross-component
XL	Significant unknowns, external dependencies, new patterns needed
XXL	Too many unknowns - needs spike or breakdown first

Approach 3: Example-Based Definition

Skip abstract definitions entirely. Just keep a reference list of 2-3 completed items per size. As the team completes more work, update the examples. This is the most practical approach because it grounds sizing in your team's actual experience.

Converting T-Shirt Sizes to Numeric Values

Eventually, you'll need numbers - for velocity tracking, capacity planning, or reporting to stakeholders. Here's how to convert.

Common Conversion Tables

Linear Conversion (simplest):

XS	S	M	L	XL	XXL
1	2	3	5	8	13

This maps directly to Fibonacci, which is convenient if your team later transitions to story points.

Weighted Conversion (reflects exponential growth):

XS	S	M	L	XL	XXL
1	3	5	8	13	21

This better reflects the reality that an XL isn't just "5 times bigger than an XS" - it's proportionally more uncertain.

Hours-Based Conversion (for time-focused teams):

XS	S	M	L	XL	XXL
2h	4h	1d	3d	1w	2w+

Use this only if your organization requires hour-based reporting. Most Agile practitioners discourage it because it conflates estimation with commitment.

When to Convert (and When Not To)

Convert when:

• Moving from roadmap planning to sprint planning
• Tracking velocity across sprints
• Forecasting delivery dates
• Reporting to stakeholders who need numeric projections

Don't convert when:

• Doing initial backlog sizing (keep it fast and rough)
• Having roadmap discussions with non-technical stakeholders
• The team is new to estimation (let them get comfortable with relative sizing first)

T-Shirt Sizing vs Other Estimation Techniques

Aspect	T-Shirt Sizing	Planning Poker	Affinity Estimation	Bucket System
Speed Per Item	30-60 seconds	2-5 minutes	10-20 seconds	15-30 seconds
Best Batch Size	20-100 stories	10-20 stories	50-200 stories	30-100 stories
Precision	Low (5-6 categories)	Moderate (10+ values)	Low-Moderate	Moderate
Learning Curve	None	Medium	Low	Low
Velocity Tracking	Requires conversion	Direct	Requires conversion	Direct
Best For	Roadmaps, new teams	Sprint planning	Large backlog triage	Medium backlogs
Stakeholder Friendly	Very high	Low	Medium	Low

Common estimation progression:

1. T-shirt sizing for initial roadmap and backlog prioritization
2. Affinity estimation for rapid large-backlog sizing
3. Planning Poker for sprint-level story estimation

Teams don't need to "graduate" from T-shirt sizing - it remains useful for roadmap discussions even on mature teams.

When to Use T-Shirt Sizing

T-shirt sizing is the right choice when:

• Your team is brand new to Agile - Start here. No learning curve, no debates about what numbers mean. Get comfortable with relative estimation before adding complexity.
• You're sizing a large backlog - Need to estimate 50+ stories in an hour? T-shirt sizing is the only technique fast enough.
• You're doing roadmap planning - Executives don't care about Fibonacci. "This feature is Large, that one is Small" communicates perfectly.
• Cross-functional groups are estimating - When designers, marketers, and developers estimate together, T-shirt sizes are the common language.
• You need a quick first pass - "Is this quarter's work mostly Mediums, or do we have several XLs?" helps with capacity conversations without detailed estimation.
• Stakeholders need rough sizing - "The migration is an XL, the new dashboard is a Medium" is more useful to a PM than "the migration is 34 story points."

When NOT to Use T-Shirt Sizing

T-shirt sizing falls short when:

• You need precise capacity planning - If your Sprint Planning requires knowing exactly how many items fit into a sprint, you need story points and velocity tracking.
• You need to track velocity - T-shirt sizes don't add up mathematically. "We completed 3 Larges and 5 Smalls" doesn't tell you if that's more or less than last sprint without conversion.
• Your team has established story point calibration - If your team already thinks fluently in Fibonacci, T-shirt sizing adds a translation step without adding value.
• Individual stories need detailed comparison - When the difference between a 5 and an 8 matters (is this story small enough for a sprint?), you need numeric precision.

Use Planning Poker for sprint-level estimation. Use Affinity Estimation if you need to size more than 50 items very quickly and already have a numeric scale.

Running T-Shirt Sizing for Remote Teams

T-shirt sizing adapts well to remote work because sessions are short and the scale is simple.

Synchronous (video call):

• Use Miro, Mural, or FigJam with columns labeled XS through XL
• Each person drags sticky notes into size columns
• Discuss items where people disagree
• Timebox to 45 minutes for 30-50 items

Async (distributed timezones):

• Share the backlog in a spreadsheet or Jira board
• Each person adds their size estimate over 24-48 hours
• Flag items with disagreement for a 15-minute sync call
• Record consensus sizes

Jira setup:

• Create a custom field called "T-Shirt Size" (dropdown: XS, S, M, L, XL, XXL)
• Use Jira plugins like Easy Agile or Agile Poker for interactive sessions
• If needed, create a separate numeric field for converted story points

Miro template approach:

• Create columns for each size
• Add all stories as sticky notes
• Team silently sorts stories into columns
• Discuss and resolve any stories in different columns

Common T-Shirt Sizing Mistakes

Mistake 1: Treating Sizes as Exact Time Estimates

What it looks like: "A Medium is 3 days. This is a Medium, so it'll be done by Wednesday."

Why it's a problem: T-shirt sizes represent relative complexity, not calendar commitments. A Medium means "about the same effort as other Mediums" - not a specific duration.

Fix: Use sizes for relative comparison and planning. If you need dates, convert to story points and use velocity-based forecasting.

Mistake 2: Too Many Size Categories

What it looks like: Team uses XS, S, SM, M, ML, L, XL, XXL, XXXL - nine categories.

Why it's a problem: More categories defeats the purpose. You've reinvented numeric estimation with worse labels. The value of T-shirt sizing is speed through constraint.

Fix: Stick to 5 sizes (XS, S, M, L, XL). Add XXL only as a "too big, must split" flag.

Mistake 3: No Reference Stories

What it looks like: "Is this a Medium? What even is a Medium on this team?"

Why it's a problem: Without calibration, the same feature might be called Small by one person and Large by another. Estimates become inconsistent and useless.

Fix: Before your first session, pick 1-2 completed items for each size. Keep these visible during every sizing session.

Mistake 4: Skipping the Simultaneous Reveal

What it looks like: "I think this is a Large." Everyone nods.

Why it's a problem: The first person to speak anchors everyone else. This destroys the independent thinking that makes group estimation accurate.

Fix: Always reveal simultaneously - hold up fingers, flip cards, or use a digital tool that hides estimates until everyone submits.

Mistake 5: Using T-Shirt Sizes for Sprint Commitment

What it looks like: "We have capacity for one XL, two Ls, and three Ms this sprint."

Why it's a problem: Without numeric conversion, you can't actually verify this. Does one XL = two Ls? Does two Ls = three Ms? The math doesn't work without defining explicit ratios.

Fix: Convert to story points before sprint planning, or accept that T-shirt sizing is for rough planning only.

Mistake 6: Never Updating Size Definitions

What it looks like: Team defined sizes six months ago. Since then, their codebase has grown, standards have changed, and "Medium" doesn't mean what it used to.

Why it's a problem: Estimation accuracy degrades as the team's reference frame shifts.

Fix: Revisit reference stories every quarter during a Sprint Retrospective. Update examples to reflect current complexity.

T-Shirt Sizing Maturity: From Beginner to Advanced

Stage 1: Getting Started (First 1-3 Sprints)

What to expect:

• Wide disagreement on what each size means
• Some items take 2-3 minutes to resolve instead of 30 seconds
• Team defaults to "everything is a Medium"
• Frequent questions about "what does Large mean?"

Focus on:

• Establishing clear reference stories for each size
• Keeping sessions short (30 minutes max)
• Not worrying about conversion yet - just get comfortable with relative sizing

Stage 2: Building Consistency (Sprints 4-8)

What to expect:

• Most items sized in under 30 seconds
• Disagreements happen mainly on L and XL items
• Team naturally starts breaking down XLs before sizing
• Sizes become predictable enough for rough planning

Focus on:

• Introducing a conversion table (sizes to story points)
• Tracking how many items of each size the team completes per sprint
• Using sizes for quarterly roadmap conversations with stakeholders

Stage 3: Integrated Estimation (Sprint 9+)

What to expect:

• T-shirt sizing flows naturally into Planning Poker for sprint-level refinement
• Team uses T-shirts for roadmap, story points for sprints
• Conversion ratios are well-calibrated to actual team performance
• Stakeholders understand and use the sizing language

Focus on:

• Refining conversion ratios based on actual delivery data
• Using sizing data for release forecasting
• Training new team members using established reference stories

Industry Examples

SaaS Product Team

Sizing a quarterly roadmap:

• XS: Add tooltip to existing feature
• S: New email template with merge tags
• M: Self-service billing portal for customers
• L: SSO integration (SAML + OIDC)
• XL: Multi-tenant data isolation redesign

How they use it: Product Manager and Engineering Lead size the next quarter's features in a 30-minute session. The result feeds into capacity allocation: "We can fit one XL, two Ls, and several S/M items this quarter."

E-Commerce Platform

Sizing a product backlog:

• XS: Update shipping label format
• S: Add "gift wrap" option to checkout
• M: Implement product recommendation carousel
• L: Build loyalty points system
• XL: Migrate payment processing to new provider

How they use it: During release planning, the team estimates 80+ backlog items in under an hour. They convert to story points only for the items entering the next two sprints.

Healthcare Application

Sizing compliance-related features:

• XS: Update privacy policy display
• S: Add audit log entry for a new action
• M: Implement role-based access control for a new module
• L: Build HIPAA-compliant patient data export
• XL: Implement end-to-end encryption for messaging

How they use it: The compliance officer participates in T-shirt sizing sessions because the scale is intuitive. They flag "any L or XL touching PHI needs a compliance review spike first."

Mobile App Development

Sizing a feature backlog across iOS and Android:

• XS: Fix padding on settings screen (both platforms)
• S: Add "share" button to user profiles (both platforms)
• M: Implement biometric login (each platform separately)
• L: Build offline sync with conflict resolution
• XL: Add real-time chat with push notifications

How they use it: Platform differences mean the same feature can be different sizes. "Biometric login is a Small on iOS (Face ID is well-documented) but a Medium on Android (fragmented hardware support)."

Agency / Consulting

Sizing client project proposals:

• XS: Landing page from template ($2-5K)
• S: Custom WordPress site (5-10 pages) ($5-15K)
• M: E-commerce site with payment integration ($15-40K)
• L: Custom web application with user management ($40-100K)
• XL: Enterprise platform with integrations ($100K+)

How they use it: Sales and delivery teams use T-shirt sizes in proposals. "This project is a Large based on our reference projects" gives clients and delivery teams a shared understanding before detailed estimation begins.

Best Practices

Before the session:

• Post reference stories where everyone can see them
• Pre-sort the backlog - skip items that are obviously XS or obviously XL
• Share the backlog 24 hours in advance for complex items

During the session:

• Timebox each item to 60 seconds (including brief discussion)
• If an item takes more than 2 minutes to size, mark it for a separate deep-dive
• Sort by confidence: size the obvious ones first to build momentum
• Use "XXL" as a trigger to split, not as a valid estimate

After the session:

• Record sizes immediately in your backlog tool
• Flag items that need more research (spikes) before they can be sized
• Convert to story points only when work moves toward sprint planning

Facilitation tips:

• Rotate the facilitator each session
• For large backlogs (50+), use silent sorting (affinity-style) first, discuss disagreements after
• If the team frequently disagrees, your size definitions need updating - not your team

Conclusion

T-shirt sizing works because it trades precision for speed and accessibility. You don't need precision in early planning - you need direction. Is this feature a Small effort or a Large one? That answer unlocks roadmap conversations, capacity planning, and backlog prioritization without the overhead of detailed estimation.

Key takeaways:

1. Use 5 sizes (XS through XL) - more categories defeats the purpose
2. Establish reference stories - they're your calibration tool
3. Reveal simultaneously - independent estimation prevents anchoring
4. 60 seconds per item - if it takes longer, the item needs refinement, not more estimation
5. Convert to story points for sprint planning - T-shirt sizes are for rough planning, not capacity commitments
6. T-shirt sizing and story points complement each other - sizes for roadmaps, points for sprints
7. Update your references quarterly - what "Medium" means changes as your team and codebase evolve

Start by sizing your current backlog in a single 30-minute session. You'll be surprised how much clarity a simple Small/Medium/Large conversation creates - and how fast your team can move when estimation stops feeling like a chore.

Continue Reading

Frequently Asked Questions

Frequently Asked Questions (FAQs) / People Also Ask (PAA)