T-Shirt Sizing Estimation: How to Size a Roadmap, With Example

8 min read ยท 2026-10-25

T shirt sizing estimation, usually written T-shirt sizing, is a quick way to estimate work by putting each item into a relative size bucket, such as XS, S, M, L and XL, instead of giving it hours or story points. Teams use it early in planning, when items are still rough and the goal is to compare them and see what fits in a quarter, not to commit to exact dates.

This guide shows how to define your sizes so they mean the same thing to everyone, how to run a sizing session in under two hours, and how to turn sizes into a capacity check for your roadmap. It includes a six-week plan to introduce the practice, a filled-in quarterly example, who does what, and how to present a sized roadmap to leadership without the sizes being read as promises.

The roadmap at a glance

Goal: Every candidate item for next quarter has an agreed T-shirt size, the sized list fits the team's capacity, and stakeholders understand what the sizes do and do not promise. Duration: 6 weeks

  1. Define the sizes (Week 1)

    Agree on what each size means for your team.

    • Choose the scale, for example XS, S, M, L and XL, and decide whether you need XXL for items that must be split.
    • Give each size a rough range in person-weeks or sprints, written as a guide, not a rule.
    • Pick one or two past items the whole team remembers as reference examples for each size.
    • Write the definitions on one page and share them with the team and stakeholders.

    Milestone: A one-page size guide with a range and a reference item for each size, agreed by the team.

  2. Prepare the candidate list (Weeks 1-2)

    Have every item ready to be sized in one session.

    • Collect next quarter's candidate items from the backlog, stakeholder requests and strategy themes.
    • Write a short description for each: the problem, the expected outcome and any known constraints.
    • Flag items with big unknowns, such as a new vendor or an unclear requirement.
    • Send the list to the team two days before the session.

    Milestone: A candidate list with a one-paragraph description for every item, shared before the session.

  3. Run the sizing session (Week 2)

    Give every item a size the team agrees on.

    • Walk through the reference items first so everyone calibrates to the same scale.
    • For each item, let the product manager explain it, then have everyone vote on a size at the same time.
    • When votes differ, ask the highest and lowest voters to explain, then vote again.
    • Mark any item sized XL or above for splitting, and note the main assumption behind each size.

    Milestone: Every candidate item has a size and a one-line assumption, with oversized items flagged for splitting.

  4. Split and refine big items (Weeks 3-4)

    Turn oversized or uncertain items into pieces the team can plan.

    • Split each XL item into smaller items that each deliver something usable.
    • Run a short spike on items with big unknowns, then size them again.
    • Re-size any item whose scope changed after stakeholder review.
    • Keep the history of size changes so you can explain them later.

    Milestone: No item larger than L remains on the candidate list, and every spike has a written result.

  5. Fit sizes to capacity (Weeks 4-5)

    Check that the sized list fits what the team can actually do.

    • Convert each size to a planning value, such as the midpoint of its range in person-weeks.
    • Work out team capacity for the quarter after holidays, support duty and planned maintenance.
    • Fill the quarter in priority order until capacity runs out, and leave a buffer for unplanned work.
    • Move the items that do not fit to a clearly labeled later column.

    Milestone: A quarter plan where the total planning value of committed items is within capacity, with the buffer shown.

  6. Present and review (Weeks 5-6)

    Share the sized roadmap and learn from the actuals later.

    • Present the roadmap with sizes, the capacity check and the items that did not fit.
    • Explain that sizes are ranges and that dates firm up as items move closer.
    • Log actual effort for each item when it finishes.
    • At the end of the quarter, compare sizes with actuals and adjust the size guide.

    Milestone: Roadmap approved by stakeholders, and a date set for the end-of-quarter size review.

T-shirt sizing vs story points vs hours

All three are ways to estimate effort, but they suit different moments. Hours are concrete and work for small, well-understood tasks. Story points are relative numbers that many Scrum teams use for backlog items they will build within the next few sprints. T-shirt sizes are coarse relative buckets that work best for larger items months ahead, when details are missing.

Many teams use T-shirt sizes for the roadmap and story points or task estimates once an item is broken down for a sprint. The two do not need to add up exactly. The T-shirt size answers "roughly how big, compared with other items". The sprint estimates answer "exactly what will we do in the next two weeks".

How to define your sizes

Sizes only work if everyone means the same thing. Tie each size to a rough range of effort and a real past item. The ranges below are a common starting point for one product team planning a quarter, measured in person-weeks. Adjust them to your team's size and sprint length.

Keep the gaps between sizes growing as items get bigger. Larger items carry more uncertainty, so the ranges should widen too. If you need a number for capacity math, map each size to a single planning value, such as the midpoint of the range, and keep that mapping on the same page as the definitions.

  • XS: a few days of work for one person, no unknowns.
  • S: about one to two person-weeks, well understood.
  • M: about three to six person-weeks, some open questions.
  • L: about eight to sixteen person-weeks, several parts or dependencies.
  • XL: more than that, or too uncertain to size. Split it before you plan it.

Example: sizing a quarterly roadmap

Picture a product team of five engineers and a designer planning the next quarter for a B2B web app. After holidays, on-call duty and maintenance, they have about fifty person-weeks for roadmap work. They keep about a quarter of that, roughly twelve person-weeks, as a buffer for unplanned work and plan against the remaining thirty-eight.

The team used the midpoints of its ranges as planning values: 1.5 person-weeks for S, 4.5 for M and 12 for L. The committed items total 34.5 person-weeks, inside the thirty-eight available. Adding the audit log admin view would have pushed the plan past that line, so it moved to next quarter. The XL item never entered the plan as one block. Splitting it showed that only the first part was urgent.

  • Single sign-on for enterprise customers (L, owner: tech lead): depends on the identity provider setup. Committed.
  • New onboarding checklist (M, owner: product manager): design ready, low risk. Committed.
  • Export to CSV from reports (S, owner: engineer): well understood. Committed.
  • Billing page redesign (M, owner: designer): needs finance sign-off on wording. Committed.
  • Audit log (XL, split into L for core logging and M for the admin view): core logging committed, admin view moved to next quarter.
  • Mobile app notifications (L): did not fit. Shown in the later column with a note.

How to run a sizing session

Invite the people who will build the work: engineers, designers and QA, plus the product manager to explain each item. Keep the session to ninety minutes or less, and plan on a few minutes per item. If you have more than about twenty items, split the session.

Use simultaneous voting so the first opinion does not anchor the rest. In a room, people can hold up cards. Remote teams can use a planning poker app or a simple poll. In Jira, many teams add a custom select list field for the size so they can filter and report on it. Record the size and the main assumption in the item itself, not in someone's notes.

Who does what

Sizing works when the people who do the work give the sizes and the people who set priorities decide the order. Mixing those roles leads to sizes that match what stakeholders hope for.

Write these roles into the planning calendar so everyone knows when their input is due.

  • Product manager: prepares the candidate list, explains each item and owns the final priority order.
  • Engineers, designers and QA: give the sizes and flag unknowns and dependencies.
  • Tech lead or engineering manager: facilitates the session, owns the size guide and the capacity numbers.
  • Stakeholders: review the sized roadmap and trade items in or out, without changing the sizes.

How to present a sized roadmap to stakeholders

Show the roadmap with three columns: now, next and later, and a size label on each item. Add a small capacity bar showing planned work against team capacity, with the buffer marked. Stakeholders can see at a glance why some requests sit in the later column.

Say clearly that sizes are ranges, not dates. When someone asks for a date on an L item, give a range and say when it will firm up, for example after the design phase. When a stakeholder wants to add an item, ask which item of a similar size should move out. That keeps the trade-off visible and the plan inside capacity.

Common mistakes to avoid

  • Using sizes without written definitions lets each person mean something different, so publish one page with a range and a reference item for each size.
  • Letting the most senior person speak first anchors everyone else, so vote on sizes at the same time and discuss only the gaps.
  • Planning XL items as one block hides most of the risk, so split anything above L before it enters the quarter.
  • Treating sizes as delivery dates sets the team up to miss them, so present sizes as ranges and firm up dates as items get closer.
  • Filling the whole quarter with sized work leaves no room for surprises, so keep a buffer for bugs, support and unplanned requests.
  • Never comparing sizes with what really happened keeps the same errors going, so log actual effort and review the size guide every quarter.

Frequently asked questions

What is T-shirt sizing in estimation?

It is a relative estimation method where items are placed into size buckets such as XS, S, M, L and XL. It is fast and works well for rough planning, like quarterly roadmaps, when details are still missing.

How do you convert T-shirt sizes to story points or time?

Agree on a planning value for each size, such as the midpoint of a range in person-weeks or a story point number. Write the mapping next to your size definitions and use it only for capacity checks. Re-estimate in detail when the item is broken down for a sprint.

When should you use T-shirt sizing instead of story points?

Use T-shirt sizes for large items that are weeks or months away, where precision is not possible yet. Use story points or task estimates once items are refined and close to being built. Many teams use both at different stages.

Who should take part in T-shirt sizing?

The people who will do the work, such as engineers, designers and QA, should give the sizes. The product manager explains each item and owns the priority order. Stakeholders review the result but should not change the sizes.

What do you do with an XL item?

Split it into smaller items that each deliver something useful, then size those. If it cannot be split because of unknowns, run a short spike first. Avoid planning an XL item as one block in a quarter.

Generate this roadmap with AI