T-Shirt Sizing: A Fast Alternative to Planning Poker for Quick Estimations

When your backlog is overflowing and you need to estimate dozens of user stories quickly, traditional planning poker sessions might feel too time-consuming. Enter t-shirt sizing—a streamlined estimation technique that trades some precision for significant speed gains. This relative sizing method uses familiar clothing sizes (XS, S, M, L, XL) to help agile teams quickly categorize work items and make faster prioritization decisions.

In this comprehensive guide, you'll learn exactly when t-shirt sizing outperforms planning poker, how to implement it effectively, and how to convert these estimates into actionable story points for sprint planning.

What is T-Shirt Sizing in Agile Estimation?

T-shirt sizing is a relative estimation technique where teams assign clothing sizes to user stories, features, or epics based on their perceived complexity, effort, and risk. Instead of debating whether a story is 5 or 8 story points, team members simply ask: "Is this small, medium, or large?"

The standard t-shirt sizing scale includes:

XS (Extra Small): Trivial changes, minimal effort
S (Small): Simple tasks, well-understood work
M (Medium): Standard complexity, typical user story
L (Large): Complex features requiring multiple tasks
XL (Extra Large): Major features spanning multiple sprints
XXL (Double Extra Large): Epics or initiatives requiring further breakdown

This metaphorical scale leverages intuitive understanding—everyone knows the relative difference between a small and large t-shirt—making it accessible even to stakeholders without deep technical knowledge.

T-Shirt Sizing vs Planning Poker: Key Differences

While both techniques use relative estimation principles, they serve different purposes and work best in different contexts.

Speed and Granularity

Planning poker uses the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) which provides more granularity and forces teams to think carefully about the differences between estimates. A planning poker session for 10 stories might take 45-60 minutes as teams discuss, debate, and converge on specific point values.

T-shirt sizing, with only 5-6 categories, moves much faster. The same 10 stories could be estimated in 15-20 minutes because teams spend less time debating the difference between adjacent sizes. This speed comes at the cost of precision—you can't distinguish between a "small-medium" and "medium" story the way you can differentiate between 5 and 8 points.

Use Case Focus

Planning poker excels at sprint-level estimation when teams need accurate forecasting for iteration planning. The numerical story points integrate directly with velocity calculations, making capacity planning straightforward.

T-shirt sizing shines during backlog refinement and portfolio planning when you need to estimate dozens or hundreds of items quickly. It's ideal for initial triaging, roadmap planning, and helping product managers make prioritization decisions before stories are ready for sprint commitment.

Participant Involvement

Planning poker actively engages the entire development team, with each member revealing their estimate simultaneously to prevent anchoring bias. The discussion that follows conflicting estimates surfaces important implementation details and risks.

T-shirt sizing can be more collaborative and inclusive, often involving product owners, designers, and even stakeholders in the estimation process. The simpler scale reduces intimidation and makes it easier for non-technical participants to contribute their perspective on scope and complexity.

Conversion Requirement

Planning poker estimates are immediately actionable—they're already in story points that feed into velocity tracking and sprint planning tools.

T-shirt sizing estimates typically require an additional conversion step to story points before sprint planning. This extra step can be a drawback, but the time saved during initial estimation often more than compensates for the conversion effort.

When to Use T-Shirt Sizing vs Fibonacci Points

Choose t-shirt sizing when:

Estimating large backlogs: You have 30+ items to estimate and need to move quickly
Early discovery phase: Requirements are still fuzzy and precise estimates would be false precision
Portfolio or roadmap planning: Comparing epics or major features at a high level
Mixed stakeholder sessions: Including non-technical participants who might struggle with Fibonacci numbers
Time-constrained meetings: You need rough estimates in 15-20 minutes
Initial backlog triaging: Quickly sorting new items into "small effort" vs "large effort" categories

Switch to planning poker when:

Sprint planning is imminent: Stories are well-defined and ready for team commitment
You need velocity tracking: Numerical story points integrate with sprint metrics
Precision matters: Small differences in estimate could affect sprint capacity decisions
Implementation details are clear: The team has enough context for detailed discussion
Establishing team calibration: New teams benefit from the discussion planning poker generates

Many high-performing teams use both methods strategically: t-shirt sizing for quarterly roadmap planning and new backlog items, then planning poker for stories entering the upcoming 2-3 sprints.

The Standard T-Shirt Sizing Scale Explained

Here's a practical breakdown of each size with concrete examples:

XS (Extra Small)

Estimated Effort: 1-2 hours Story Point Equivalent: 1 point Examples:

Fix a typo in user-facing text
Update a configuration value
Change button color or minor UI adjustment
Add a missing alt tag to an image

Characteristics: Requires minimal context, no uncertainty, often a single-line code change.

S (Small)

Estimated Effort: 2-8 hours (half day to full day) Story Point Equivalent: 2-3 points Examples:

Add a simple validation rule to a form
Create a new API endpoint using existing patterns
Update an email template with new copy
Add basic unit tests to an existing component

Characteristics: Well-understood work following established patterns, minimal dependencies.

M (Medium)

Estimated Effort: 1-3 days Story Point Equivalent: 5 points Examples:

Implement a new form with multiple fields and validation
Create a report with data aggregation and visualization
Add filtering capability to an existing list view
Refactor a component to improve performance

Characteristics: Standard user story complexity, may require coordination across a couple of files or components, some design decisions needed.

L (Large)

Estimated Effort: 3-5 days (most of a sprint) Story Point Equivalent: 8 points Examples:

Build a new feature with multiple interconnected components
Implement third-party integration with authentication flow
Create a complex data migration with multiple steps
Design and implement a new database schema with relationships

Characteristics: Touches multiple parts of the system, requires technical design, potential for unexpected complexity, should ideally be broken down further.

XL (Extra Large)

Estimated Effort: 1-2 sprints Story Point Equivalent: 13 points Examples:

Build a complete new module or subsystem
Implement multi-step workflow with state management
Complete redesign of a major feature area
Significant technical debt resolution affecting multiple areas

Characteristics: Spans multiple sprints, definitely should be broken into smaller stories, useful for initial planning but too large for sprint commitment.

XXL (Double Extra Large)

Estimated Effort: Multiple sprints or quarters Story Point Equivalent: Epic-level (20+ points or undefined) Examples:

Launch new product feature category
Complete platform migration (e.g., database change)
Implement enterprise-grade security overhaul
Build entirely new product area

Characteristics: These are epics or initiatives requiring decomposition into multiple features and stories before estimation becomes meaningful.

Converting T-Shirt Sizes to Story Points

When it's time to move stories from the backlog into sprint planning, you'll need to convert t-shirt sizes into numerical story points. Here are three proven conversion approaches:

Method 1: Direct Mapping (Simplest)

Create a straightforward conversion table aligned with the Fibonacci sequence:

XS → 1 point
S → 2 points
M → 5 points
L → 8 points
XL → 13 points
XXL → Break down into smaller items

This method is fast and creates consistency across your backlog. The downside is it assumes all "Medium" items are truly equivalent, which may not reflect nuanced differences within each category.

Method 2: Range-Based Conversion (More Flexible)

Allow a range of story points for each t-shirt size:

XS → 1 point
S → 2-3 points
M → 3-5 points
L → 5-8 points
XL → 8-13 points

When moving a story into sprint planning, the team does a quick planning poker session within the range. For example, a story sized as "Medium" would be estimated as 3, 5, or possibly 8 points based on a brief discussion. This preserves some granularity while benefiting from the initial quick categorization.

Method 3: Reference Story Calibration (Most Accurate)

Identify reference stories that represent each t-shirt size for your team:

XS Reference: "Add missing email validation to signup form" (1 point)
S Reference: "Implement forgot password feature" (3 points)
M Reference: "Create user profile page with edit capability" (5 points)
L Reference: "Build activity feed with filtering" (8 points)

When converting, compare the new story to your references: "Is this more like our Small reference or Medium reference?" Then assign the corresponding story point value. This grounds estimates in actual team experience and improves calibration over time.

Pros and Cons of T-Shirt Sizing

Advantages

Speed: The most significant benefit. T-shirt sizing can be 2-3x faster than planning poker for large backlogs, freeing up time for actual development or more valuable discussions.

Accessibility: Non-technical stakeholders find t-shirt sizing less intimidating than numerical estimates. Product managers, designers, and business stakeholders can meaningfully participate without feeling out of their depth.

Reduced Analysis Paralysis: Fewer options mean less time debating whether something is 5 or 8 points. Teams make faster decisions and move on, avoiding diminishing returns from over-analysis.

Excellent for Uncertain Work: When requirements are fuzzy, t-shirt sizing acknowledges the uncertainty without creating false precision. It's honest about what you know and don't know.

Scales Well: Whether you're estimating 10 items or 100, the technique remains manageable. Planning poker becomes exhausting with very large backlogs.

Disadvantages

Less Precision: You can't distinguish between items within the same size category. This lack of granularity can make capacity planning trickier.

Conversion Overhead: The additional step of converting to story points adds process complexity. If not done carefully, information can be lost during conversion.

Velocity Tracking Challenges: You can't calculate velocity directly from t-shirt sizes without conversion. This makes sprint-to-sprint metrics more complicated.

Team Calibration Takes Longer: What one person considers "Medium" might be "Large" to another. Establishing shared understanding across the team requires conscious effort and reference examples.

Risk of Over-Simplification: The ease of t-shirt sizing can lead teams to rush through estimation without surfacing important technical concerns or dependencies.

Step-by-Step Implementation Guide

Ready to introduce t-shirt sizing to your team? Follow this proven implementation approach:

Step 1: Educate the Team (15 minutes)

Explain the concept, scale, and purpose. Be clear about when you'll use t-shirt sizing (backlog refinement, roadmap planning) versus planning poker (sprint planning). Show the conversion approach you'll use.

Step 2: Establish Reference Stories (30 minutes)

As a team, review recently completed work and identify reference examples for each size category. Document these with brief descriptions:

"Our 'Small' reference is like when we added CSV export to the dashboard"
"Our 'Medium' reference is like the user notification preferences feature"

These references become your calibration baseline.

Step 3: Practice Session (30 minutes)

Estimate 10-15 stories from your backlog together. For each story:

Product owner reads the story (1 minute)
Brief clarifying questions (2 minutes max)
Team members simultaneously reveal their size estimate (thumbs, cards, or chat)
If consensus, move on; if split, brief discussion (2 minutes max)
Record the agreed size and move to next story

Track your time—you should complete 10 stories in under 30 minutes.

Step 4: Establish Norms (10 minutes)

Decide on process details:

Who participates in t-shirt sizing sessions?
What happens if someone thinks an item is too large or too small for the scale?
When will you convert sizes to story points?
How often will you revisit your reference stories?

Document these decisions where the team can reference them.

Step 5: Regular Refinement Sessions

Schedule regular backlog refinement using t-shirt sizing. Many teams do:

Weekly 30-minute session: Estimate new items as they're added
Monthly roadmap review: High-level sizing of upcoming quarters
Ad-hoc sizing: Quick estimates during product discovery

Step 6: Retrospect and Adjust

After 2-3 sprints, discuss what's working and what isn't:

Are estimates improving in accuracy?
Is the conversion process smooth?
Do reference stories still resonate?
Is the team over- or under-estimating any particular size?

Adjust your process based on feedback.

Real-World Use Cases and Success Stories

Use Case 1: Startup Product Discovery

Context: An early-stage SaaS startup needed to evaluate 50+ feature ideas for their MVP roadmap.

Approach: The product team (PM, designer, 2 developers) spent 90 minutes t-shirt sizing all 50 ideas. They used:

XS/S: Could include in MVP
M: Consider for MVP if high priority
L/XL: Post-MVP features

Result: Clear prioritization framework emerged. They identified 15 small features for MVP, deferred 8 medium-priority items to post-launch, and created a "big bets" list of 5 large features for later roadmap. The rapid estimation allowed them to start building immediately rather than spending weeks in analysis paralysis.

Use Case 2: Enterprise Quarterly Planning

Context: A 40-person engineering organization needed to plan work across 5 teams for the next quarter.

Approach: Product and engineering leadership used t-shirt sizing during quarterly planning:

Portfolio review: Sized all proposed initiatives (L, XL, XXL)
Capacity allocation: Mapped team capacity in "medium equivalents" (1 team ≈ 15 mediums per quarter)
Commitment: Selected initiatives that fit capacity
Handoff: Individual teams later refined their initiatives into stories using planning poker

Result: Clear quarterly commitments made in one day-long planning session. Teams knew their focus areas and could dive into detailed sprint planning with confidence. The high-level sizing prevented over-commitment while maintaining flexibility for teams to adjust estimates as they learned more.

Use Case 3: Technical Debt Triage

Context: Development team had accumulated 80+ technical debt items and needed to prioritize which to address.

Approach: Engineering lead facilitated a 45-minute session where the team:

Sized effort required to fix each debt item (t-shirt sizing)
Rated business impact (also using S/M/L)
Created a 2x2 matrix: "High Impact + Small Effort" items became priorities

Result: Identified 12 high-impact, small-effort technical debt items that could be tackled in spare cycles. Also surfaced 3 large-effort items that needed dedicated sprint focus. The quick sizing enabled data-driven prioritization without elaborate analysis.

Facilitation Tips for Effective T-Shirt Sizing Sessions

Create Time Pressure (Productive Constraints)

Set a timer for each story—typically 2-3 minutes maximum. When time expires, move on even if full consensus isn't reached. If the team is stuck between two sizes, choose the larger one and note it for later breakdown. Time pressure prevents over-analysis and keeps energy high.

Use Silent Voting

Just like planning poker, have participants simultaneously reveal their size estimate (using hand signals, cards, or digital tools). This prevents anchoring bias where the first person to speak influences everyone else's estimate.

Focus Discussions on Outliers

If most people say "Medium" and one person says "XL," spend 2 minutes understanding why. Often the outlier has identified a technical constraint or dependency others missed. If everyone says "Medium" or only one size category apart, move on immediately without discussion.

Break Down XXL Immediately

If something gets sized as XXL, pause estimation and ask: "Can we break this into smaller chunks right now?" Spend 5 minutes identifying 2-4 sub-items, then estimate those. This prevents your backlog from filling up with un-estimatable epics.

Revisit Reference Stories Quarterly

Your team's capabilities and understanding evolve. Every quarter, review your reference stories:

Do they still represent accurate size categories?
Have you outgrown some references (what was "Large" is now "Medium")?
Do you need new examples for recently introduced technology or patterns?

Update references to reflect current reality, improving future estimate accuracy.

Combine with Priority Scoring

Don't estimate in a vacuum. After sizing a batch of stories, spend 5 minutes doing a quick priority discussion. This helps product owners see: "We have 10 small items and 3 large items—given priorities, which should enter the next sprint?"

Use Visual Grouping

When estimating many items at once, use a virtual or physical board with columns for each size. After initial estimates, visually group stories:

XS    | S     | M     | L     | XL
------|-------|-------|-------|-------
Story1| Story3| Story5| Story8| Story10
Story2| Story4| Story6| Story9|
      |       | Story7|       |

This creates a visual sense of the backlog distribution and makes it easier to spot items that might need re-sizing ("Does Story7 really belong with the other Mediums?").

Document Assumptions and Risks

When a story receives a larger size estimate, quickly note why. Examples:

"Sized Large due to unclear API requirements"
"Medium estimate assumes existing authentication system can be reused"
"Small, but only if we don't need iOS support"

These notes become invaluable when you later convert to story points or begin actual implementation.

Common Pitfalls and How to Avoid Them

Pitfall 1: Treating T-Shirt Sizes as Absolute Measures

Teams sometimes try to define exact hour ranges for each size (e.g., "Small = 4-8 hours"). This defeats the purpose of relative estimation and creates false precision.

Solution: Always estimate relative to your reference stories, not to time. Ask "Is this bigger or smaller than our Small reference?" not "How many hours will this take?"

Pitfall 2: Skipping the Conversion Step

Some teams try to use t-shirt sizes directly for sprint planning and velocity tracking. This rarely works well because the sizes are too coarse-grained for accurate capacity planning.

Solution: Accept that conversion to story points is necessary. Build it into your workflow: stories get t-shirt sized during initial refinement, then converted to points when they're 1-2 sprints away from development.

Pitfall 3: Allowing Anchoring Bias

If the product owner says "I think this is Medium" before the team estimates, it influences everyone's judgment.

Solution: Have the PO present the story without mentioning any size. Team members then simultaneously reveal estimates. Only after voting does discussion happen.

Pitfall 4: Estimating Without Enough Context

T-shirt sizing's speed can lead to superficial estimates where important details are missed.

Solution: Before estimating any story, ensure these basics are covered:

What is the user outcome we're trying to achieve?
Are there known technical constraints or dependencies?
Has anyone on the team done something similar before?

If you can't answer these, the story needs more refinement before estimation.

Integrating T-Shirt Sizing with Planning Poker Tools

Many teams wonder if they need different tools for t-shirt sizing versus planning poker. The good news: most modern estimation tools support both.

When using dedicated planning poker applications like Planning Poker App, look for these features to support t-shirt sizing:

Custom Card Decks: Select or create a deck with XS, S, M, L, XL, XXL options instead of Fibonacci numbers
Quick Mode: Some tools offer streamlined voting for rapid estimation sessions
Conversion Templates: Save your size-to-points mapping for consistent conversion
Reference Story Library: Store your reference examples within the tool for easy access during sessions
Bulk Estimation: Import multiple stories and estimate them in sequence without leaving the interface

If your current tool doesn't support t-shirt sizing, you have options:

Use emojis or tags: Many tools allow custom tags—use XS, S, M, L, XL as tags on stories
Custom fields: Create a "T-Shirt Size" field separate from story points
Naming conventions: Temporarily prefix story titles with [S] or [M] during bulk estimation sessions
Spreadsheet hybrid: Do initial t-shirt sizing in a spreadsheet, then import with converted story points

The key is maintaining traceability: even after conversion to story points, keep the original t-shirt size visible. This helps with retrospectives and recalibration.

Making the Choice: When T-Shirt Sizing Is Right for Your Team

T-shirt sizing isn't universally better or worse than planning poker—it's a specialized tool that excels in specific contexts. Consider adopting t-shirt sizing if your team experiences:

Estimation fatigue: Planning poker sessions feel like they take forever
Large backlog anxiety: You have dozens of unestimated items and don't know where to start
Stakeholder disconnection: Non-technical partners feel excluded from estimation
Early-stage uncertainty: You're constantly estimating fuzzy ideas that haven't been fully thought through
Portfolio planning needs: You need to compare large initiatives across multiple teams or quarters

You might want to stick primarily with planning poker if:

Your backlog is relatively small (under 20 unestimated items)
Stories are well-defined and ready for sprint commitment when estimated
Your team is new and needs the detailed discussion planning poker encourages for team building
You have plenty of time for thorough estimation sessions
Your tooling and metrics are deeply integrated with story point-based velocity

Remember: you don't have to choose exclusively. Many successful teams use t-shirt sizing for initial backlog population and roadmap planning, then switch to planning poker as stories approach active development. This hybrid approach captures the speed benefits of t-shirt sizing while maintaining the precision of planning poker where it matters most.

Conclusion: Speed Without Sacrificing Value

T-shirt sizing represents a pragmatic approach to agile estimation that acknowledges a fundamental truth: not all estimates need the same level of precision. When you're evaluating dozens of potential features for a roadmap, the difference between 5 and 8 story points matters far less than quickly categorizing work into "quick wins" versus "major investments."

By adopting t-shirt sizing strategically—for backlog refinement, portfolio planning, and initial triaging—teams can reclaim hours of meeting time while maintaining the relative estimation principles that make agile forecasting work. The key is understanding when speed trumps precision and when the reverse is true.

Start small: try t-shirt sizing for your next backlog grooming session. Establish reference stories, set time limits, and experience how much ground you can cover in 30 minutes. Then gradually expand the practice to roadmap planning and larger estimation challenges.

The goal isn't to replace planning poker entirely but to add another tool to your estimation toolkit—one that's optimized for the fast-moving, high-uncertainty situations that increasingly characterize modern product development.

Ready to try t-shirt sizing with your team? Start a free Planning Poker session with customizable card decks that support both Fibonacci and t-shirt sizing scales.

About Planning Poker App: We provide online planning poker and t-shirt sizing tools for distributed agile teams. Start free sessions with no account required, or upgrade to Team plans for advanced features like Linear and Jira integration, session analytics, and team workspaces.