User Story Mapping

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)

1. Pick the work: 10–20 epics or features you want to compare.
2. Calibrate quickly: Agree on one example for S, M, L from your history.
3. Silent first pass: Each person suggests a size. Keep it to 30 seconds per item.
4. Discuss only the outliers: If your spread is XS to XL, talk. If it’s S/M, move on.
5. 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)

1. Affinity wall: Lay items left‑to‑right from smaller to larger.
2. Light buckets: Draw soft bands for XS/S/M/L/XL and nudge items into them.
3. 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.

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

SEE HOW

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:

1. Weighted Shortest Job First
2. MoSCoW
3. KANO
4. Stack Ranking
5. 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!

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
  

Free Trial: Easy Agile TeamRhythm