Agile Estimation Techniques: A Deep Dive Into T-Shirt Sizing

TL;DR: What T‑shirt sizing is, where it shines, how to run it with a real team, how it relates to story points, and how to avoid common traps.
A quick scene
Friday afternoon. You’ve inherited a backlog that sprawls for metres. Someone asks, “Roughly how long to ship the payments revamp?” Your team glances at the ceiling. You don’t need a perfect answer, you need a safe first pass that helps you plan sensibly. That’s where T‑shirt sizing earns its keep.
What is T‑shirt sizing in agile?
T‑shirt sizing is a lightweight way to estimate relative effort using XS, S, M, L, XL. It’s great for roadmaps, release planning, and early discovery, moments when detail is thin and the goal is direction, not exact dates.
Think of it as a sketch: enough shape to discuss options and make trade‑offs. As work moves closer to delivery, translate sizes into more precise estimates (for most teams, that’s story points).
New to story points or need a refresher? Read How to use story points for agile estimation and 10 reasons why you should use story points.
When to use T‑shirt sizes vs story points
Use T‑shirt sizes when:
- You’re scanning a large backlog to spot big items and cut noise
- You’re sequencing epics on a roadmap or release plan
- You’re aligning many teams for a Program Increment and need a first pass on effort
Switch to story points when:
- You’re shaping a commitment for a sprint or release
- The team understands the work well enough to discuss risk, complexity, and unknowns
Simple rule of thumb - story point estimates are best for sprint planning. Affinity mapping, bucket systems, dot planning, and T-shirt sizing are better for roadmap and release planning.
How to run a T‑shirt sizing session (two practical patterns)
The main thing to keep in mind is you don’t need ceremony to get this right. What you need is speed and shared understanding.
1) Small set of items (do this in 20–30 minutes)
- Pick the work: 10–20 epics or features you want to compare.
- Calibrate quickly: Agree on one example for S, M, L from your history.
- Silent first pass: Each person suggests a size. Keep it to 30 seconds per item.
- Discuss only the outliers: If your spread is XS to XL, talk. If it’s S/M, move on.
- Capture the decision: Write the size on the card/issue and one sentence on why (risk, dependency, unknown). Future‑you will thank you.
2) Huge backlog (affinity + buckets)
- Affinity wall: Lay items left‑to‑right from smaller to larger.
- Light buckets: Draw soft bands for XS/S/M/L/XL and nudge items into them.
- One pass of challenges: People can move cards they strongly disagree with, but they must explain what information would change the estimate.
If you prefer a card‑based approach, swap in Planning Poker and use T‑shirt cards instead of numbers.
Here's an example of how T-shirt sizing would play out at a fashion retailer (we know, it's a bit on the nose). The team had a quarter‑long goal to reduce checkout drop‑off. In their first hour, they T‑shirt sized five ideas:
- New payment provider (XL) - Big integration, contract, risk
- Guest checkout (M) - Some UX and auth changes
- Auto‑fill postcode (S) - Low risk, measurable uplift
- Order status emails (M) - Copy, events, templates
- Retry logic on payments (L) - Engineering heavy, few dependencies
They sequenced S → M → L and left the XL until discovery removed the scariest unknowns. Two sprints later, they pointed the M/L items and committed. The XL became a spike with clear questions.
Where sizing goes sideways and how to recover
Converting sizes to points then leaving them untouched
Why it bites: People treat the conversion as a promise, plans harden, trust erodes when reality changes.
Try this: If you convert for prioritisation, mark those items as provisional, replace the size with true points during refinement, and keep a short note on what changed. For more on timing and trade offs, see 5 agile estimation tips.
Treating sizes as dates
Why it bites: A neat row of S and M turns into calendar commitments, and the team inherits a deadline they never made.
Try this: Share ranges based on throughput, update as you learn, and keep the conversation focused on outcomes.
One scale across many teams
Why it bites: S in one team is M in another, cross team comparisons become arguments not insight.
Try this: Keep scales local, and during PI Planning compare sizes only to surface risk and dependencies. Use a shared program board instead of chasing numeric parity.
Endless debate on edge cases
Why it bites: The time you spend arguing dwarfs the cost of being slightly wrong.
Try this: Timebox each item, discuss only the outliers, capture the uncertainty in one sentence, and move on. If a decision is still sticky, schedule a small spike with a clear question.
Skipping calibration examples
Why it bites: What counted as M last quarter slowly drifts, new joiners anchor on guesses.
Try this: Keep a living set of examples for S, M, and L in Jira, refresh them when your tech or team changes, and link those issues in your session notes.
Loud voices steer the room
Why it bites: Anchoring replaces thinking, quieter people disengage.
Try this: Start with a silent first pass, reveal together, then invite two or three different voices to speak before the most senior person. A little psychological safety goes a long way.
Jumping from XL epics to sprint commitments
Why it bites: The team commits to fog, you get churn and rework.
Try this: Slice the work first, use story mapping to find thinner slices, and refine before you point.
Mixing size and value
Why it bites: Small items with real impact wait behind large but low value work, momentum stalls.
Try this: Keep a separate value signal, a one line impact hypothesis is enough, then weigh size against value when you sequence. The planning guide above has a simple pattern you can copy.
No breadcrumb of why you chose a size
Why it bites: You cannot learn from your estimates later and the next session restarts from scratch.
Try this: add one sentence on risk, dependency or unknown to each decision, then check a sample in your next retro. Use action-driven retrospectives to close the loop.
Recording sizes and keeping plans honest in Jira
- For shaping and tracking epics, keep sizes and notes on a shared board the team actually uses every day. A user story map gives context and helps when you later point stories. Easy Agile TeamRhythm supports mapping, lightweight estimation and retros all inside Jira.
- When several teams are involved, use a program board to visualise objectives, dependencies and dates. Easy Agile Programs keeps this view in Jira so you can plan PI events without spreadsheets.
- For public roadmaps, keep it simple and visual. Easy Agile Roadmaps helps you share a plan stakeholders actually read.
Regardless of the type of agile project you're working on or the estimation process you choose, the more you practice, the quicker your team will become master estimators. We recommend trying a couple of different methods to see which one feels most comfortable for your team.
FAQ (for searchers and skimmers)
- What’s the point of T‑shirt sizing if we’ll use story points later?
It lets you compare big pieces quickly so you can decide what to pursue, sequence sensibly, and avoid wasting refinement time on the wrong items.
- Can we convert sizes to story points?
You can, locally, for prioritisation, just mark them clearly and replace with real points before a sprint commitment. Don’t reuse another team’s scale.
- Stakeholders want dates. How do we answer without over‑promising?
Share ranges based on today’s sizes and the team’s recent throughput, and update as items shrink and you learn more. For a practical way to connect goals, value and delivery, see How to make plans that actually ship and We simplified our OKRs.
- How do we run T‑shirt sizing across many teams?
Keep it team‑local first. During PI planning, compare sizes only to surface risk and dependencies, not to rank teams. Use a program board to keep the conversation grounded. Start with our PI Planning guide.
Related Articles
- Workflow
10 reasons why you should use story points for estimation
There are many good reasons why so many scrum and agile teams are adopting story points.
1. Fast estimation
User story points allow you to quickly estimate the work involved in each item on your backlog, and how much work you can get done in a sprint or release.
2. Build consensus and collaboration
If one team member estimates 5 story points, but another estimates 12, it's an opportunity for the team to discuss what work is involved.
One person may have a more efficient way of doing things, or the other person may have a better understanding of the steps involved in doing the work. This discussion will help them share ideas, create a common understanding, build consensus, and create a more accurate estimation.Compare this to estimating time. If you ask each team member to estimate the amount of time involved in a task, you’ll get 5+ different answers. Timing depends on experience and understanding. But most team members will agree on the effort required to complete a story, which means you can reach a consensus and move on with your story mapping or sprint planning much more quickly.
3. No artificial deadlines
Estimating time instead of story points forces you to come up with an artificial deadline, which can create unnecessary pressure (and probably won't be all that accurate).
Story points more accurately and practically reflect reality. In most cases, there is no set deadline - only ensuring tasks are done efficiently and in the right order of prioritization.4. Better planning and forecasting
Story points can help you plan better in advance. For example, if you know that Johnny is going on holiday for a week, you can adjust your sprint so that your team doesn't over-commit. Or you can find another way to increase your capacity, like bringing on another team member or reducing scope.
5. Zoom in on the details
Story points force your team to think through the work involved in an upcoming sprint, and consider what's realistic. It's a time for your details-oriented team members to shine - and time for your big-picture thinkers to understand what needs to happen to bring their plans to life.
6. Get commitment
When your team knows they can achieve what's planned and they’re confident in their velocity, it's easier to get them to commit to the work and follow through confidently.
7. Be more adaptable
If the team size changes (maybe you add a new member or someone moves to another role), you have a built-in system to update your velocity (i.e. how many stories you can complete in a sprint) and adapt your workload accordingly.
8. Be just accurate enough
Story points help you estimate what your team can get done in a given amount of time. This kind of accuracy means smoother releases that go to plan - and is especially valuable when you have multiple teams with multiple dependencies.
But at the same time, story pointing makes it clear that your work is only an estimation, and you're not committing to getting X done in Y amount of hours. You won't know how long something will take until you do it - there are nearly always unexpected things that pop up.
Other methods might give you more precise timing, but it’s not practical to spend 30 minutes discussing the work that goes into every single story on your backlog. It’s much more practical to assign an “accurate enough” number, plan your sprint, and get to work.
9. Better capacity planning
You might not be able to fit all your top priorities into a release, especially if they’re complex, risky, or time-consuming. But story points can help you easily identify one or two smaller stories to fill your capacity every sprint or release.
Using story points also encourages you to find ways to increase your team’s capacity (rather than working longer hours). If you can mitigate risk, find ways to reduce effort, and bring the right people in the room to make complex tasks more simple… you’ll be able to get through more stories, more quickly.
10. Measure and improve performance
Story points can help you measure and improve performance by asking your team questions like:
- Did you complete all the work assigned during the sprint?
- Is your velocity going up or down over time, as you get better at agile?
- Was your story points estimate accurate?
- If not, how could you optimize your team's performance and ensure you work or plan better together?
Does everything in your backlog need user story points?
Some teams don't assign story points to every item in their backlog. They might just assign them to the user stories. They might avoid assigning user story points to bugs that come up during the sprint, particularly if they're not related to any of the stories originally mapped to the sprint. This makes sense since it's often tricky to estimate a bug - some take very little effort to resolve, while others are quite complex.
Your backlog might also include smaller jobs or technical tasks that would take anywhere from a few minutes or a few hours to complete. These tasks may not have story points assigned if they require very little effort.But it’s important to note that these tasks still matter. They still deliver value back to the user. And they're essential as part of your goal: to deliver working software. But you can't always plan for them or estimate them ahead of time.
So, how do you incorporate them into your workflow?
You might need to discuss some different ideas and strategies with your team.
For example, you could set aside a buffer in your capacity to allow for an average amount of bugs and other jobs that don’t get story-pointed. That way, you can stay on track with the stories you have assigned to the sprint, while getting other items ticked off the list.
Either way, if your team is working on tasks that don’t have story points, you have to consider the impact on capacity. You will need to adapt, assess whether the sprint goal is still doable, and adjust your plans accordingly.
What happens if you get the estimate wrong?
While you should aim to make your user story point estimates as accurate as possible, you might have under or overestimated the amount of risk, effort, and complexity involved in bringing a story to life.
This might mean you don't get all the work planned for your sprint done. Maybe you need to move some of it over to the next sprint, which will mean reprioritizing and adjusting your user story map.
Fortunately, this process is pretty straightforward if you use digital user story mapping software like Easy Agile TeamRhythm.
Retrospectives or sprint reviews are a good time to discuss any issues with your team where estimates were off. Take some time to go through what happened, understand why more or less effort was required, and discuss how you might do more accurate estimates in the future.
Assign story points inside Easy Agile TeamRhythm
With Easy Agile User Story Maps for Jira, you can add and edit story point estimates directly on your story map. Simply select the story or issue and edit the story point field.
It will automatically update your sprint/version statistics with new totals, so you can see your capacity, arrange stories into sprint/version swimlanes, ensure you’re making the most of your velocity, and avoid over-committing.
Plus, your whole team has access to the user story board and estimates - perfect for in-house or remote user story mapping, online collaboration, and updating estimates at any point in the process.
Curious about Easy Agile User Story Maps? Features include so much more than story points, like:- Drag and drop prioritization
- Visualized customer journeys inside Jira
- Sprint/version swimlanes for organizing stories
- Easily add or edit stories inside your story map
- See sprint/version statistics at a glance
- Easy collaboration with team members
- Agile Best Practice
5 Agile Estimation Tips To Help With Backlog Prioritization
Backlog prioritization is a never-ending task for product owners and product managers. As priorities evolve in response to changing business needs, or even as work is completed, or adjustments to team resourcing are made, it's important to maintain focus on the work that will deliver the most value by keeping your backlog in good shape. Agile estimation techniques can make prioritizing your backlog faster and easier.
So, let's take a look at some specific methods to prioritize your backlog and see how agile estimation can help deliver the most value to your end-users and stakeholders.
5 ways to prioritize a backlog
Of course, there are more than five ways to prioritize work items in a backlog. But, we've picked a few of our favorites that, when combined with an agile estimation process, help keep our product backlog prioritized so we can breeze through sprint planning.
1. Weighted Shortest Job First
Wow, is that a mouthful! Let's use the "WSJF" acronym to refer to this SAFe technique. Not as intimidating as it sounds, WSJF is a simple formula that assigns a business value to product backlog items.
WSJF = Cost of Delay ÷ Job Duration
Cost of Delay is the sum of three relative metrics:
- User/Business Value: the relative importance of the work item.
- Time Criticality: the decline of user/business value over time.
- Risk Reduction: the reduction of business or technical risk.
To determine the relative size for Cost of Delay, think of the lowest business value, the smallest decline in value over time, and the least risk reduction as a 1 value. The same as with Fibonacci sequence story point estimation, adjust that score appropriately when comparing work items to score them relative to one another.
The Job Duration is also expressed in relative terms. If you estimate your work items using relative estimation with story points, the story point value equals the Job Duration.
If you're using this technique to prioritize a large amount of work in a backlog where some items have only been t-shirt sized, convert your t-shirt sizes to standard Fibonacci numbers and use that value.
Warning: Be careful with converting t-shirt sizes to story points. You'll need a way to flag the t-shirt size work items that you converted to story points. You and your Scrum Master need to recognize those as t-shirt level estimations rather than the real story point estimates that come with fully refined work items.
See more at a glance in Easy Agile TeamRhythm, to make prioritizing your backlog faster
💡Tip: Add up to three extra fields on issue cards
2. MoSCoW
Must-have, should-have, could-have, and won't-have are the buckets used to prioritize a backlog with the MoSCoW technique. The product team defines these designations based on the product's unique features and competitive offerings.
Each work item falls into one of those categories. The easiest part of this process is sending Won't-have items directly to the trash and getting them out of your way. Next, prioritize must-haves first and then should-haves. The could-have items naturally fall to the bottom of the backlog.
Take these items through your regular refinement meetings with your team members, and assign each item a t-shirt size or story point value. You're then ready to add the right amount of work items to your sprints or releases based on your teams' velocity or the number of story points they expect to finish during a sprint.
3. Kano
The Kano model of prioritization uses five classifications:
- Must-be: the basic functionality that your users expect.
- Attractive: a pleasant surprise for your users, but no one is going to be upset if it's not there.
- One-Dimensional: work items that make your users happy and will disappoint them if they aren't part of your product.
- Indifferent: work items that are unimportant to your customers. Often, these work items represent technical debt or enhancements that help the software development team develop more efficiently or work in the latest versions of their tech stack — but your customers really don't care about them.
- Reverse: the process of undoing a previous feature or update. If you've ever built a feature or made a UI update that your users hated, you understand reverse work items. Oops. Unfortunately, sometimes these are necessary evils, especially when it comes to security features or transitioning users to a new product after retiring a legacy product.
Like the MoSCoW method, you'll estimate these work items during refinement and then add them to your iteration or release plan. But, different from MoSCoW, you may want to balance out your sprints and releases with work items from each classification.
4. Stack Ranking
The most brutal of all prioritization techniques, stack ranking forces teams to have a linear rank of work items, which means there is only one top priority, one second priority, one third priority, and so on. Brutal!
Once you get used to it, stack ranking is a useful way to force product managers to make tough choices between work items. Even if two work items can be completed during the same sprint, it's up to the PO to determine which one gets done first, and then that choice is reflected in the sprint backlog.
Often, this job becomes easier when it's put in dire terms. For instance, if you only had one day to attract new users to your product, what work would you want in production? BOOM! There's your top priority.
The nice thing with stack ranking is that it allows POs to slide smaller work items into current sprints when other higher-priority work is too large. Adding the larger work item over-commits the team based on their velocity. Those small work items serve to fill up sprints so teams can maintain velocity and be as productive as possible. So, just because a two-story point work item is two-thirds the way down the backlog doesn't mean it will never get done.
5. Story Mapping
Story mapping helps you visualize the customer's journey through your product from start to finish. (Yep, we stole that straight from our other excellent article on story mapping.) For advanced story mappers, take what you’ve learned about story mapping, and think about how you can add MoSCoW or Kano techniques to your story maps.
Perhaps your epic backbone at the top of the user story map could represent the buckets in the MoSCoW method?
If you're like us, your story mapping sessions are productive brainstorming activities, and you'll leave the sessions with way more work than you can accomplish. By applying MoSCoW or Kano principles to the stories in your user journeys, you’ll discover the most important stories to prioritize and the stories that can wait for a later release.
Building agile estimation into backlog prioritization
We've given you five different techniques to corral your work items into an organized, prioritized, value-delivering product backlog:
- Weighted Shortest Job First
- MoSCoW
- KANO
- Stack Ranking
- Story Maps
We've also shown you ways to incorporate agile estimates like t-shirt sizes and story points into your prioritization process to keep your team delivering the most important work while maintaining velocity and dazzling your customers and stakeholders.
We encourage you to take these ideas, share them with your team, and give them a try. If you need help using the Story Map concept, try Easy Agile TeamRhythm. However your team prioritizes its product backlog, remember to put the most important work first and then adjust those priorities as needed. Keep it easy and keep it agile!
- Agile Best Practice
The Problem with Agile Estimation
The seventh principle of the Manifesto for Agile Software Development is:
Working software is the primary measure of progress.
Not story points, not velocity, not estimates: working software.Jason Godesky, Better Programming
Estimation is a common challenge for agile software development teams. The anticipated size and complexity of a task is anything but objective; what is simple for one person may not be for another. Story points have become the go-to measure to estimate the effort involved in completing a task, and are often used to gauge performance. But is there real value in that, and what are the risks of relying too heavily on velocity as a guide?
Agile estimation
As humans, we are generally terrible at accurately measuring big things in units like time, distance, or in this case, complexity. However, we are great at making relative comparisons - we can tell if something is bigger, smaller, or the same size as something else. This is where story points come in. Story points are a way to estimate relative effort for a task. They are not objective and can fluctuate depending on the team's experience and shared reference points. However, the longer a team works together, the more effective they become at relative sizing.
The teams that I coach have all experienced challenges with user story estimation. The historical data tells us that once a story exceeds 5 story-points, the variability in delivery expands. Typically, the more the estimate exceeds 5 points, the more the delivery varies from the estimate.
Robin D Bailey, Agile Coach, GoSourcing
Scale of reference
While story points are useful as an abstraction for planning and estimating, they should not be over-analyzed. In a newly formed team, story points are likely to fluctuate significantly, but there can be more confidence in the reliability of estimations in a long-running team who have completed many releases together. Two different teams, however, will have different scales of reference.
At a company level, the main value I used to seek with story points was to understand any systemic problems. For example, back when Atlassian released to Server quarterly, the sprints before a release would blow out and fail to meet the usual level of story point completion. The root cause turned out to be a massive spike in critical bugs uncovered by quality blitz testing. By performing better testing earlier and more regularly we spread the load and also helped to de-risk the releases. It sounds simple looking back but it was new knowledge for our teams at the time that needed to be uncovered.
Mat Lawrence, COO, Easy Agile
Even with well-established teams, velocity can be affected by factors like heightened complexity with dependencies scheduled together, or even just the average number of story points per ticket. If a team has scheduled a lot of low-complexity tickets, their process might not handle the throughput required. Alternatively having fewer high-complexity tickets could drastically increase the effort required by other team members to review the work. Either situation could affect velocity, but both represent bottlenecks.
Any measured change in velocity could be due to a number of other factors, like capacity shifting through changes in headcount with team members being absent due to illness or planned leave. The reality is that the environment is rarely sterile and controlled.
Relative velocity
Many organizations may feel tempted to report on story points, and velocity reports are readily available in Jira. Still, they should be viewed with caution if they’re being used in a ‘team of teams’ context such as across an Agile Release Train. The different scales of reference across teams can make story points meaningless; what one team considers to be a 8-point task may be a 3-point task for another.
To many managers, the existence of an estimate implies the existence of an “actual”, and means that you should compare estimates to actuals, and make sure that estimates and actuals match up. When they don’t, that means people should learn to estimate better.
So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.Ron Jefferies
Co-Author of the Manifesto for Agile Software Development
Story Points RevisitedSeeking value
However, story points are still a valuable tool when used appropriately. Reporting story points to the team using them and providing insights into their unique trends could help them gain more self-awareness and avoid common pitfalls. Teams who are seeking to improve how they’re working may wish to monitor their velocity over time as they implement new strategies.
Certainly, teams working together over an extended period will come to a shared understanding of what a 3 story point task feels like to them. And there is value in the discussion and exploration that is needed to get to that point of shared understanding. The case for 8 story points as opposed to 3 may reveal a complexity that had not been considered, or it may reveal a new perspective that helps the work be broken down more effectively. It could also question whether the work is worth pursuing at all, and highlight that a new approach is needed.
The value of story points for me (as a Developer and a Founder) is the conversations where the issue is discussed by people with diverse perspectives. Velocity is only relatively accurate in long-run teams with high retention.
Dave Elkan, Co-CEO, Easy Agile
At a company level, story points can be used to understand systemic problems by monitoring trends over time. While this reporting might not provide an objective measure, it can provide insights into progress across an Agile Release Train. However, using story point completion as a measure of individual or team performance should be viewed with considerable caution.
Story points are a useful estimation tool for comparing relative effort, but they depend on shared points of reference, and different teams will have different scales. Even established teams may notice velocity changes over time. For this reason, and while velocity reporting can provide insights into the team's progress, it must be remembered that story points were designed for an estimation of effort, rather than a measure. And at the end of the day, we’re in the business of producing great software, not great estimates.
Looking to focus your team on improvement? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives linked to your agile board in Jira, to improve your ways of working and make your next release better than the last. Turn an action item into a Jira issue in just a few clicks, then schedule the work on the user story map to ensure your ideas aren’t lost at the end of the retrospective.
Many thanks to Satvik Sharma, John Folder, Mat Lawrence, Dave Elkan, Henri Seymour, and Robin D Bailey for contributing their expertise and experience to this article.