> ## Documentation Index
> Fetch the complete documentation index at: https://docs.charle.agency/llms.txt
> Use this file to discover all available pages before exploring further.

# T-shirt Sizing

> How to estimate work using standardized time ranges

T-shirt sizing is a relative estimation method that uses standardized categories (XS, S, M, L, XL, XXL) instead of precise hours. Each size represents a time range with a minimum, maximum, and average—providing flexibility while maintaining consistency.

## The Size System

Every t-shirt size maps to a specific time range:

| Size    | Time Range   | Average   | When to Use                                                     |
| ------- | ------------ | --------- | --------------------------------------------------------------- |
| **XS**  | 0-30 mins    | 15 mins   | Trivial changes: fixing typos, updating text, tiny CSS tweaks   |
| **S**   | 1-2 hours    | 1.5 hours | Small work: simple component updates, straightforward bug fixes |
| **M**   | 3-6 hours    | 4.5 hours | Standard features: moderate complexity, typical task size       |
| **L**   | 8-16 hours   | 12 hours  | Complex features: multiple components, significant logic        |
| **XL**  | 24-40 hours  | 32 hours  | Major features: substantial work spanning multiple days         |
| **XXL** | 40-120 hours | 80 hours  | Very large deliverables: multi-week projects, full modules      |

<Info>
  **Averages are rounded to the nearest 15 minutes** for clean scheduling. This ensures time allocations work smoothly with standard calendar increments.
</Info>

### Not Required

There's also a **Not Required** option for requirements that don't apply to a particular scope (e.g., design not needed for a backend-only task).

## Why Ranges Instead of Fixed Hours?

Ranges acknowledge the inherent uncertainty in software estimation:

<Tabs>
  <Tab title="Minimum (Best Case)">
    **Everything goes smoothly**

    * No unexpected complications
    * Clear requirements
    * Existing patterns to follow
    * Minimal QA issues

    Example: M size minimum = 3 hours (when work flows perfectly)
  </Tab>

  <Tab title="Average (Expected Case)">
    **Typical delivery with normal friction**

    * A few minor hiccups
    * Some clarification needed
    * Normal QA feedback
    * One or two revision rounds

    Example: M size average = 4.5 hours (what we quote and expect)
  </Tab>

  <Tab title="Maximum (Worst Case)">
    **Complications arise**

    * Scope less clear than expected
    * Technical challenges surface
    * More QA issues than usual
    * Multiple feedback rounds

    Example: M size maximum = 6 hours (the cap—client never pays more)
  </Tab>
</Tabs>

## What's Included in the Size?

T-shirt sizes represent the **total time** needed to complete the deliverable, including:

<CardGroup cols={2}>
  <Card title="Core Work (80%)" icon="code">
    **For Development:**

    * Writing code
    * Implementing features
    * Building functionality

    **For Design:**

    * Creating mockups
    * Designing interfaces
    * Visual work
  </Card>

  <Card title="QA & Feedback (20%)" icon="bug">
    **For Development:**

    * Internal QA review time
    * Fixing bugs found in QA
    * External QA feedback fixes

    **For Design:**

    * Client feedback rounds
    * Revisions based on feedback
    * Design iteration cycles
  </Card>
</CardGroup>

<Warning>
  QA time and client feedback are **included in the t-shirt size**, not added on top. A Medium task (3-6 hours) includes core work PLUS QA/feedback within that range.
</Warning>

### The 80/20 Split in Practice

Internally, CharleOS splits the average time for scheduling purposes:

**Example: M size development (average = 270 minutes)**

* **Development:** 210 minutes (80% core work)
* **QA budget:** 60 minutes (20% = 54 mins, rounded UP to 60), split as:
  * Initial Internal QA Review: 30 minutes (50% of QA budget)
  * First Internal QA Fixes: 30 minutes (50% of QA budget, used if QA fails)

This split helps PMs allocate:

* Core work → Assigned developer
* Initial QA → QA person has budgeted time for review
* First QA fixes → Developer has budgeted time if changes needed
* Subsequent iterations → PM sets estimates manually

**What happens if QA fails multiple times:**

* First round: Initial QA review (30 min) + fixes (30 min) = 60 min covered
* Second round: PM allocates additional time manually based on scope
* Budget exhausted: Additional time may become overage (non-billable)

<Info>
  The 80/20 split is for **internal scheduling only**. Clients see the total t-shirt size, not the breakdown.
</Info>

## How to Choose a Size

Selecting the right t-shirt size requires considering multiple factors:

### 1. Complexity

<AccordionGroup>
  <Accordion title="Low Complexity → Smaller Sizes" icon="circle-check">
    * Work is straightforward
    * Clear requirements
    * Existing patterns to follow
    * Minimal logic or edge cases

    **Examples:**

    * Update footer links (XS)
    * Add a new field to a form (S)
  </Accordion>

  <Accordion title="Moderate Complexity → Medium Sizes" icon="circle-half-stroke">
    * Some technical challenge
    * Multiple components involved
    * Standard business logic
    * Normal testing needs

    **Examples:**

    * Add product filtering (M)
    * Build contact form with validation (M)
  </Accordion>

  <Accordion title="High Complexity → Larger Sizes" icon="circle-exclamation">
    * Significant technical challenge
    * Multiple interconnected components
    * Complex business rules
    * Extensive testing required

    **Examples:**

    * Multi-step checkout flow (L or XL)
    * Real-time collaboration features (XL or XXL)
  </Accordion>
</AccordionGroup>

### 2. Unknowns and Discovery

The more uncertainty, the larger the size:

| Unknown Factor           | Impact                              | Example                                         |
| ------------------------ | ----------------------------------- | ----------------------------------------------- |
| **Clear requirements**   | No change                           | "Make button blue"                              |
| **Some ambiguity**       | Size up by 1                        | "Improve navigation UX"                         |
| **Significant unknowns** | Size up by 2, or do discovery first | "Integrate with third-party API (unclear docs)" |
| **Complete unknown**     | Discovery task first                | "Research best approach for real-time sync"     |

<Note>
  When unknowns are high, consider a separate **discovery task** (usually S or M) before estimating the implementation.
</Note>

### 3. Dependencies

Dependencies increase risk and coordination overhead:

<Tabs>
  <Tab title="No Dependencies">
    **Self-contained work**

    * No reliance on other work
    * Can be completed independently
    * Minimal coordination needed

    Size as normal based on complexity.
  </Tab>

  <Tab title="Few Dependencies">
    **Some coordination required**

    * Relies on 1-2 other pieces
    * Needs API or component from another task
    * May block or be blocked briefly

    Consider sizing up by 1 if dependencies are complex.
  </Tab>

  <Tab title="Many Dependencies">
    **High coordination overhead**

    * Relies on multiple other pieces
    * Requires cross-team coordination
    * High risk of being blocked

    Size up by 1-2 levels, or break into smaller pieces.
  </Tab>
</Tabs>

### 4. Similar Past Work

Compare to completed tasks with similar scope:

<Steps>
  <Step title="Find Similar Tasks">
    Search for tasks with comparable requirements, complexity, and tech stack.
  </Step>

  <Step title="Review Actual Time">
    Check how long they actually took (not just the estimate). Look at the billable time and any overage.
  </Step>

  <Step title="Identify Patterns">
    * Did they consistently overrun? → Size up
    * Were they efficient? → Similar size is safe
    * Did specific clients or codebases cause issues? → Account for that
  </Step>

  <Step title="Adjust for Differences">
    Is this task simpler or more complex than the reference? Adjust size accordingly.
  </Step>
</Steps>

## Sizing Guidelines by Type

### Design Work

| Size   | Typical Work                            | Includes                                   |
| ------ | --------------------------------------- | ------------------------------------------ |
| **XS** | Icon design, minor style tweaks         | Quick mockup, minimal feedback             |
| **S**  | Single page mockup                      | 1-2 feedback rounds                        |
| **M**  | Multi-page flow (3-5 screens)           | Full design + client revisions             |
| **L**  | Complete section redesign (10+ screens) | Multiple iterations, detailed feedback     |
| **XL** | Full site redesign                      | Extensive revisions, stakeholder alignment |

### Development Work

| Size   | Typical Work                             | Includes                                |
| ------ | ---------------------------------------- | --------------------------------------- |
| **XS** | Typo fix, config change                  | Quick test, deploy                      |
| **S**  | Simple CRUD endpoint, basic component    | Unit tests, QA review                   |
| **M**  | Standard feature with UI + logic         | Full testing, bug fixes                 |
| **L**  | Complex feature with multiple components | Integration testing, multiple QA rounds |
| **XL** | Major feature or module                  | Comprehensive testing, extensive QA     |

## Common Sizing Mistakes

### Mistake 1: Not Accounting for QA/Feedback

<Tabs>
  <Tab title="❌ Wrong">
    **Thinking:** "The coding will take 3 hours, so I'll size it S (1-2 hours)"

    **Problem:** Forgot to account for QA fixes and testing time.
  </Tab>

  <Tab title="✅ Correct">
    **Thinking:** "The coding will take 3 hours, plus 1 hour for QA fixes = 4 hours total, so M (3-6 hours)"

    **Why:** T-shirt sizes include the full deliverable, not just the happy path.
  </Tab>
</Tabs>

### Mistake 2: Ignoring Client or Codebase Factors

<Tabs>
  <Tab title="❌ Wrong">
    **Thinking:** "This is a standard feature, always size it M"

    **Problem:** Didn't account for this client's legacy Vue 2 codebase being painful to work in.
  </Tab>

  <Tab title="✅ Correct">
    **Thinking:** "Standard feature is usually M, but this client's codebase adds complexity. Size it L to account for the friction."

    **Why:** Context matters—tech debt, poor docs, and messy code increase time.
  </Tab>
</Tabs>

### Mistake 3: Using XXL as a Catch-All

<Tabs>
  <Tab title="❌ Wrong">
    **Thinking:** "This is big and complex, so XXL"

    **Problem:** XXL becomes a black box—hard to schedule, hard to track progress, high risk.
  </Tab>

  <Tab title="✅ Correct">
    **Thinking:** "This is big, so I'll break it into 3 smaller deliverables: L + M + L"

    **Why:** Smaller pieces are easier to estimate, schedule, and deliver incrementally.
  </Tab>
</Tabs>

## Tips for Better Sizing

<AccordionGroup>
  <Accordion title="When in Doubt, Size Up" icon="arrow-up">
    If you're torn between S and M, choose M. It's better to finish early (creating banked time) than to consistently overrun. Clients prefer positive surprises.
  </Accordion>

  <Accordion title="XS Should Be Rare" icon="stopwatch">
    Reserve XS for truly trivial changes. If it requires any thought or testing, it's probably S. Most work is S or larger.
  </Accordion>

  <Accordion title="Break Up XXL" icon="scissors">
    XXL should be rare. If a requirement is XXL, consider splitting it into multiple smaller deliverables. This reduces risk and improves scheduling flexibility.
  </Accordion>

  <Accordion title="Use Historical Data" icon="clock-rotate-left">
    Review past tasks regularly to calibrate your estimates. Which sizes were accurate? Which consistently overran? Learn from patterns.
  </Accordion>

  <Accordion title="Communicate Assumptions" icon="comment">
    When estimating, note your assumptions:

    * "Assumes API docs are accurate"
    * "Includes 2 design feedback rounds"
    * "Based on similar product filter implementation"

    This helps if scope changes later.
  </Accordion>
</AccordionGroup>

## How Sizes Affect Billing

T-shirt sizes feed directly into the value-based billing formula:

```formula theme={null}
Billable = MIN(maximum, MAX(average, actual))
```

**Example: M size (3-6 hours, average 4.5 hours)**

| Scenario      | Actual Time | Billable Time       | Outcome                 |
| ------------- | ----------- | ------------------- | ----------------------- |
| **Efficient** | 3 hours     | 4.5 hours (average) | 1.5 hrs banked (profit) |
| **On Target** | 5 hours     | 5 hours (actual)    | No margin, fair         |
| **Overrun**   | 7 hours     | 6 hours (maximum)   | 1 hr overage (absorbed) |

**Key takeaways:**

* **Minimum** is never billed (you always bill at least the average if you finish early)
* **Average** is billed when you finish faster than average
* **Maximum** is the cap—client never pays more, even if you overrun

<Warning>
  Consistent overruns hurt profitability. If you're regularly exceeding the maximum, your sizing is too optimistic. Size up or improve scoping.
</Warning>

## Using T-shirt Sizes in CharleOS

### In Quotes

When creating quotes, each requirement block is assigned a t-shirt size:

1. Open the quote
2. Navigate to the requirement
3. Select a size from the dropdown
4. Optionally add sizing notes (e.g., "Assumes API is RESTful")
5. Save

The quote automatically calculates:

* Minimum total time
* Average total time (what client is quoted)
* Maximum total time (the cap)

### In Tasks

When quotes convert to tasks, the t-shirt sizes carry over:

* Task inherits the estimate
* Subtasks are created with the 80/20 split applied
* Billing cap is set to the maximum
* Actual time is tracked against the estimate

### Viewing Size Info

Hover over any t-shirt size badge in the UI to see:

* Time range (e.g., "3-6 hours")
* Average (e.g., "4.5 hours")
* What's included (core work + QA/feedback)

## Related Concepts

<CardGroup cols={2}>
  <Card title="Scoping" icon="list-check" href="/concepts/estimation/scoping">
    How to scope work effectively before applying t-shirt sizes
  </Card>

  <Card title="Billing Model" icon="calculator" href="/concepts/billing/billing-model">
    How t-shirt sizes feed into the value-based billing formula
  </Card>

  <Card title="Efficiency" icon="bolt" href="/concepts/financial/efficiency">
    How actual time vs estimates affects profitability
  </Card>

  <Card title="Creating Quotes" icon="file-text" href="/user-guide/quotes/creating-quotes">
    Step-by-step guide to applying sizes in quotes
  </Card>
</CardGroup>