5 Agile Games for Innovative Learning
Agile software development uses iteration to improve agile practices. More than that, development teams use agile principles to enhance self-organization. Improving the Scrum framework leads to improvements in rapid deliverables and product outcomes through iteration.
But taking on agile when you're not familiar with this approach can be challenging. Team members need a bridging tool. A bridging tool like virtual team building activities supports new learning activities. New learning promotes new ways of thinking that promote continuous improvement. Enter, Agile games!
Learn how these games can support team-building and promote problem-solving for better software development processes, and which agile games to look for.
What are agile games?
Agile games are online games that entire teams can play. These games were created for team-building activities. They help nurture effective teams by getting everyone to work towards a common goal. When agile teams put their heads together, communicate effectively, and take on new learning, everyone wins — including product owners.
Team building games drive innovation by encouraging a new perspective through team-building exercises. Agile games are fun, but they are also practical. This practical approach enables team members to adopt new behaviors.
When they play agile games, teams implement better working methodologies in software development. Agile games support team building through new learning activities and iteration.
Ultimately, agile games augment the good communication and self-organization of DevOps teams. The outcome of playing agile games is that your team members more rapidly assimilate agile software.
As agile teams improve their problem-solving skills, they reap multiple benefits that might have fallen along the wayside if they didn't use an agile methodology or these agile games.
Types of agile games
There are multiple agile games that you can use to familiarize new teams with agile software. Tastycupcakes developed many of these simple games as ice breakers, which encourage introverts to participate more fully in Scrum practices. These games also help build multitasking skills in high-pressure DevOps environments, which any agile coach will be happy to use.
Now that you have some groundwork to help you understand the thinking behind agile games, you’re probably keen to find out what types of games you can play to build teamwork.
Here are a few agile games to whet your appetite. This list of games goes from the shortest to the longest playing times, each with its own objective.
1. Chocolate Bar Game
Playing TimePlayers RequiredFormatObjectives5 mins4+Virtual & in-personTeam building activity for customer feedback and iteration
The Chocolate Bar Game is ideal for new teams who are unfamiliar with agile practices. Teamwork improves as the members play this game and learn more about iteration. Entire teams can also play this game to understand how to integrate customer feedback into their retrospectives.
You can either play the game in person or play an online game with remote teams.
The Chocolate Bar game works as a Scrum simulation. The goal is to create a chocolate bar as if you were taking instructions from the product owner. Development teams choose their product manager who can also be the product owner. The rest of the agile team are the customers.
The product owner acts as a facilitator, instructing team members to create a chocolate bar that appeals to the target market. This chocolate bar must be delicious and can be made from either dark chocolate, milk chocolate, or white chocolate.
Additionally, the team can select a range of fillings to improve their product. Toppings and other unique features also come into play as teams can include organic or gluten-free features that cater to a niche market.
After each iteration, the project manager provides the team with customer feedback. Customers can give the software development team (or chocolate bar creation team) a thumbs up for their creation if they approve of the chocolate made by the agile team. Customers can also give team members a thumbs down if they don’t like the initial stages of their chocolate bar creation.
Teamwork involves recording customers' responses for changes before the next iteration, which involves the chocolate bar fillings. The team members will continue building their chocolate bar, adding or subtracting fillings and toppings until most customers are happy with their creation.
As you can see, playing the Chocolate Bar Game involves repetitive iteration based on customer feedback, which is the objective of this agile game.
2. How to Hug
Playing TimePlayers RequiredFormatObjective5 mins (or less)3+Virtual onlyAgile team collaboration
How to Hug is a simple game for improving team collaboration, especially on a remote team. How to Hug is a great icebreaker when introducing new team members.
The Scrum team can access this agile team-building activity online. The entire team uploads their photos for display on the How to Hug virtual circle. The whole team can then vote to place their image at the circle's center.
Once the agile team has a central image, the rest of the members move their images to touch the Scrum Master's image at the circle's center.
Everyone has a chance to place their image at the center of the circle, and the team repeats the process. Although a simple game, this is one of those virtual team-building activities that involve lots of laughs.
Team members learn about each other during this virtual hugging session with collaboration and team bonding helping to create a great team.
3. Ball Point Game
Playing TimePlayers RequiredFormatObjective15 mins, split into 3-min sessions4+In-person & virtualAgile production process
The objective in playing Ball Point is for the Scrum team to navigate agile projects better. By understanding the agile production process, the team appreciates the importance of self-organization. Self-organization is the cornerstone for creating Scrum processes that work so that the entire team can engage in effective iteration.
Entire teams can play this game physically or online, using game icons on the virtual whiteboard.
The common goal is for the team to move a ball or several balls around the table. Team members must all touch the ball or balls once. After one team member touches the ball, the next person must do the same. The Scrum team earns a point if they successfully manage to move the ball around the table.
Each sprint lasts for three minutes, and the whole team must participate in five sprints to see who wins the Ball Point game. During the first sprint, the team discusses their strategy and takes notes to anticipate how many points they will score in the first minute.
The second minute involves moving the ball around the table. The Scrum team records their points and new learning in the third minute.
As the game progresses, teamwork intensifies as members add more balls in the following sprint rounds. As the team passes balls simultaneously, the game becomes more complex. More thinking is required in the iteration process as team members attempt to increase their scores. After each round, the teams engage in a brief retrospective to see what tactics they can use to score more points in the next sprint. Simple but effective!
4. Marshmallow Tower
Playing TimePlayer RequiredFormatObjectives20 mins4+In-person onlyIteration & collaboration
This is an in-person team building activity, and the team will need a few supplies:
- Dry spaghetti
- One yard of tape
- One yard of string
- Marshmallows
Team members must engage in this learning activity in groups of four people. The Scrum master hands out 20 pieces of spaghetti to each team, along with the other provisions.
The objective here is to build the highest marshmallow tower with these items. The marshmallow tower must be freestanding, and team members must place all the marshmallows at the top of the structure. Some agile games use one marshmallow, while others match the marshmallow numbers with the spaghetti sticks.
Inevitably, the tower collapses as the team places the marshmallow on top. But the goal is to simulate the Scrum retrospective through several iterations. The whole team must quickly regroup through good communication and collaboration to improve each successive round.
The concept sounds simple, but its execution is deceptively tricky. Teams need to collaborate quickly, and you’re sure to see plenty of towers collapse at the last second as teams scramble to place the marshmallow on top of their structures.
But, repeat the challenge several times, and you’ll see teams refine their approaches to collaboration and iterate on their earlier creations.
5. LEGO Flow Game
Playing TimePlayers RequiredFormatObjectives60-90 mins3-9In-person onlyScrum simulation, iteration, collaboration, workflow
The LEGO Flow game focuses on a Scrum simulation. Agile teams build a virtual LEGO Advent Calendar to detail work items in an efficient workflow. Each section of the workflow involves specific role players.
The common goal is to build the items, find the following advent calendar number (analysis) and then identify a set of LEGO pieces that must align with the supply source (suppliers).
The Scrum team builds (builders) the LEGO item as they progress through the game. Team members must engage in constant iteration to determine whether the build is correct and acceptable to the market representatives or product owner (acceptors).
Agile coaches will love using this game as it is an excellent tool to introduce new teams to Agile. LEGO Flow offers new teams the opportunity to engage in new learning activities through a simulated Scrum exercise.
LEGO Flow is an agile game that requires three rounds, each with its own objective. These objectives include batch and phase-driven processes together with time-boxed and flow-based processes.
After each of the three rounds, teamwork involves sprint retrospectives to understand what went well and what challenges the team encountered. The objective is to analyze the pros and cons of each sprint approach, demonstrating the benefits of teamwork. The game ends with the building of an overall Cumulative Flow Diagram.
This diagram allows the whole team to view its strategies and decisions, consider where they went wrong in each round of this agile game, and enhance their workflow.
If time allows, the Scrum master can question team members about what policy changes they would make for future sprints.
Agile games and team building activities
The whole team can transform their work-life with virtual team-building activities over Zoom. Having some fun while learning definitely beats using a physical whiteboard and sticky notes to introduce new teams to the Scrum framework.
Easy Agile apps are yet another innovative way to ease your new team into the Agile family. Dive into the world of Easy Agile Scrum Workflow for Jira that you can combine with LEGO Flow.
Related Articles
WorkflowAgile 101: A Beginner’s Guide to Agile Methodology
We’re here to talk about agile, and we don’t mean your abilities on a sports field or in a yoga studio. If you’re new to agile as a methodology, there’s a lot to learn, but the basics are simple. Agile 101 begins with understanding that agile can be applied to anything. You can use agile practices to improve your personal task management, optimize workplace efficiency, or align software teams around product development.
No matter the application, the concepts remain the same: Agile creates a continuous improvement mindset that values flexibility, adaptability, collaboration, and efficiency.
In this post, we’ll cover agile 101 basics, the benefits of agile, popular agile methodologies, and common mistakes to avoid.
Agile 101: How it compares to traditional project management
The concept of Agile has evolved, but it really took off and became popularized in software development. In recent years, the methods and guiding principles of Agile have expanded into a variety of industries that want to emphasize continuous improvement and growth.
How does agile compare to traditional project management? In short: It doesn’t. Agile is just the opposite. One of our favorite ways to compare the agile approach to classical project management is to think of them as jazz vs. classical music.
In classical music, a conductor brings a previously composed and organized piece of music to an orchestra. Then, they dictate what happens and when. This is very much the same as traditional project management, where the project manager brings a plan they have conceived on their own to their team and then proceeds to tell the team how to carry it out. The project manager lays out the steps and expects the team to follow them to the letter (or note). 🎼
Jazz, on the other hand, is collaborative. Each band member feeds off of the other, creating music in a flexible and iterative process — just like the agile process. The band, like an agile team, experiments together and freely creates music in the moment. Each iteration is a little bit different, and hopefully better, than the one that preceded it. 🎷
Project management doesn’t allow for this kind of flexibility. It relies on following a strict sequential order. Each project element must be completed before moving on to the next. Just like a waterfall, the flow of work remains the same from project to project.
Agile is non-linear. It focuses on flexibility, collaboration between team members, and delivering consistent value to stakeholders. With each iteration comes new, actionable insights into what’s working, what isn’t, and what needs to change. It’s a multidimensional way of working that removes the bottlenecks inherent in traditional project management.
Agile 101: The benefits of agile
There are many benefits to agile practices for software development projects, as well as many other industries. The general concepts of agile can be applied to all sorts of situations, and its versatility means it will evolve with the needs of your team.
Think of it as a methodology you can apply to any of your business processes for increased collaboration, optimized efficiency, and continuous improvement.
Agile helps teams and businesses:
- Work at optimal efficiency by eliminating waste
- Make more effective decisions
- Adjust as new information comes in or is discovered
- Continually meet stakeholder deliverable deadlines
- Focus on adding value for stakeholders and customers
- Understand the customer journey
- Build superior products
- Understand capacity to ensure no one over or under commits to work
- Identify roadblocks before they occur
- Spot bottlenecks that could delay work
- Collaborate and work better together
- Adapt with technological, economic, and cultural changes
- Prepare for the unexpected
- Establish processes tailored to your needs
- Improve morale and happiness
- Develop a continuous improvement mindset
Agile 101: Popular methodologies
Now that you have a better understanding of agile 101 basics and the benefits of agile, let’s discuss some of the most popular agile methodologies.
Scrum
Scrum is extremely popular in agile software development. It’s a fairly complicated process for those who are unfamiliar with it, but the basics revolve around recurring sprints that each focus on completing a set amount of work.
A Scrum is one sprint lasting 2-4 weeks. At the beginning of the sprint, the product owner decides which task will move from the main list (product backlog) to the sprint to-do list (sprint backlog). The development team, led by a Scrum Master who understands the Scrum process, works to complete the sprint backlog in the allocated time.
The Scrum team meets for daily Scrums or stand-ups that ensure everyone is on the page about possible roadblocks and what work is to be completed next. This process repeats until a product is complete or stakeholders are fully satisfied. At the end of the sprint, a retrospective is held to help the team understand what went well and what they can improve upon.
Kanban
Kanban is a fairly simple agile process that is often partially utilized within other agile methods, such as Scrum. It’s a task management tool designed to optimize efficiency by visualizing all of the required work and limiting works in progress. A Kanban workflow visually organizes tasks on Kanban boards so that work items can move forward smoothly, even as changes and adjustments are made along the way.
In its simplest form, a Kanban board is three columns (To-Do, Doing, and Done) that allow work to freely flow from one phase to the next. Trello is an example of an online Kanban board.
Kanban boards should be placed in an area of the office that’s visible to the entire team. For virtual teams, this may look like an online resource that everyone can access. This helps everyone from the top down get on the same page about action items. If anyone is wondering what’s the most important task of the day, they simply need to check the Kanban board.
Lean
Lean, along with the five lean principles, originally created by Toyota, is a guiding mindset that helps teams work more productively, efficiently, and effectively. It can be applied to various agile and software development methodologies.
Lean software development is all about improving efficiency by eliminating waste, such as reducing tasks and activities that don’t add value. It provides a clear way to scale agile practices across large or growing organizations.
Extreme programming
Extreme programming (XP) is an agile approach centered around improving software quality and responsiveness while evolving with customer requirements. The ultimate goal of extreme programming is producing high-quality results throughout every aspect of the work, not just the final product.
XP decision-making is based on five values: communication, simplicity, feedback, courage, and respect. XP’s specifics won’t apply to all situations, but the general framework can provide value to any team.
Agile 101: Best practices and mistakes to avoid
To get you started, here are our list of best practices and common agile mistakes.
Basic agile 101 best practices:
✅ See failures as a learning opportunity.
✅ Embrace change and improve your adaptability skills.
✅ Improve efficiency by eliminating tasks and activities that don’t provide value.
✅ Continually improve upon your processes.
✅ Allow plans to live, breathe, and adapt.
✅ Use retrospectives to listen, learn, and improve.
✅ Prioritize the customer journey, and make decisions based on customer needs.
✅ Utilize agile tools and resources.
Common agile mistakes:
❌ Not adapting as new information is revealed or obtained.
❌ Not being on the same page as stakeholders.
❌ Not trusting the team to ideate and develop without supervision.
❌ Sitting down for sprint planning without enough information.
❌ Not incorporating retrospective insights in the following planning session.
❌ Skipping a retrospective due to lack of time or resources.
❌ Too much testing, or not knowing when the project is actually “done.”
❌ Choosing tools that don’t take a customer-centric approach.
Agile made easy
Whether you apply agile principles to an agile task management system like a personal Kanban board or use agile to develop working software, the essence is the same. In basic terms, agile is about continuous improvement. It’s a methodology, mindset, and way of viewing the world. Agile is flexible, adaptive, collaborative, and value-driven.
Easy Agile helps teams work better with agile. We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams work better together, and deliver for your customers.
Book a 1:1 demo to learn more about our suite of Jira tools, or contact our team if you have additional questions. We offer a free, 30-day trial, so you can try out our products before making a commitment.
Agile Best PracticeAgile Ceremonies: Your Ultimate Guide To the Four Stages
This guide looks at the four ceremonies that bring one of Agile’s most popular frameworks, Scrum, to life.
Learn how each agile ritual helps empower teams and drive performance while highlighting some tips to help your organization get the most from your ceremonies.
At a glance:
- The four agile ceremonies are Sprint Planning, Daily Stand-Up, Sprint Review and Sprint Retrospective
- Ceremonies in agile facilitate visibility, transparency, and collaboration.
- Each ceremony has a clear structure and objective.
- Clear communication, flexibility, and cultural alignment are the keys to successful ceremonies.
What are the main agile ceremonies?
Agile ceremonies refer to the four events that occur during a Scrum sprint. Other forms of agile development, such as Kanban and Lean, also have similar practices.
The agile ceremonies list includes:
- Sprint Planning
- Daily Stand-Up
- Sprint Review
- Sprint Retrospective
While each ceremony is different, they facilitate the same overall purpose. The ceremonies bring teams together with a common goal under a regular rhythm, and they help teams get things done.
"With today's enterprises under increased pressure to respond quickly to the needs of their customers and stakeholders, they must bring new products to market faster and accelerate improvements to existing solutions and services." - State of Agile Report
Why are agile ceremonies important?
Agile ceremonies help organizations adapt to change and succeed. With work planned in smaller portions and over shorter timeframes, they help teams quickly shift direction and course-correct when needed. They form a key part of the broader agile approach that’s now widely adopted in organizations worldwide.
With agile ceremonies, teams in your organization can benefit from:
- Enhanced ability to manage changing priorities
- Acceleration of software development
- Increase in team productivity
- Improved business and IT alignment
It’s important to remember that while ceremonies are an essential part of Scrum, they’re just one of many rituals that help create agile teams and workplaces. To realize the true benefits of agile, you’ll need to do more than include one or more of the ceremonies into your waterfall project.
1. Sprint Planning
The Sprint Planning ceremony sets teams up for success by ensuring everyone understands the sprint goals and how to achieve them.
- Structure - The Product Owner brings the product backlog to discuss with the Development Team. The Scrum Master facilitates. Together, the Scrum Team does effort or story point estimations. The product backlog must contain all the details necessary for estimation. The Product Owner should be able to clarify any doubts regarding the product backlog.
- Attendees - The entire Scrum Team (the Development Team, Scrum Master, and Product Owner).
- Timing - At the beginning of each sprint.
- Duration - One to two hours per week of iteration. So, if you're planning a two-week sprint, your Sprint Planning should last two to four hours.
- Agile Framework - Scrum. Although Kanban teams also plan, they do it less formally and per milestone, not iteration.
Outcomes
After some team negotiation and discussion, you should have a clear decision on the work that the Development Team can complete during the sprint by the end of Sprint Planning. This is known as the sprint goal.
The sprint goal is an increment of complete work, and everyone should feel confident about the commitment.
The product backlog defines priorities that affect the order of work. Then, the Scrum Master transforms that decision into the sprint backlog.
Top tips
- Focus on collaboration rather than competition.
- Break user stories into tasks to get things more operational for the Development Team. If there's time, assign those tasks during the event.
- Factor in public holidays and any team member’s time off or vacations.
- Keep your team’s pace in mind – a track record of the time it took to implement similar user stories would be helpful.
- Focus on the product backlog and nothing else in terms of work for the sprint.
2. Daily Stand-Up
The daily stand-up brings the team together and sets everyone up for the day. The team uses this time to identify blockers and share plans for the day.
- Structure - This is an informal, standing meeting. All members of the Development Team inform everyone about what they did the day before and what they’re doing today. Members discuss any blockages they have and ask for help from the team if required. Due to time restrictions, the updates should be brief.
- Attendees - Development Team, Scrum Master, Product Owner (optional).
- Timing - Daily, usually in the morning.
- Duration - Short and sharp. No longer than 15 minutes.
- Agile framework - Scrum and Kanban.
Outcomes
The Scrum Master should clear all the blockages that slow down or prevent the Development Team from delivering. As a result, the development process might need to change.
This daily pulse check keeps the team in sync and helps build trust. Together, the group finds ways to support and help each other.
Top tips
- Use a timer to keep this meeting to 15 minutes.
- Hold your stand-up at the same time every day.
- Only discuss the work for the day ahead.
- If the team is distributed, use video conferencing with cameras on.
- Long discussions should happen after the event.
- As the stand-up encourages progress, everyone should provide an update, and everyone should feel accountable.
3. Sprint Review
The Sprint Review is the time to showcase the team’s completed work and gather feedback from stakeholders. A variety of attendees from outside the team offer valuable insights from different viewpoints. This event also helps build trust with both external and internal stakeholders.
- Structure - The Scrum Master takes on the logistics of event preparation. The Product Owner should ask stakeholders questions to gather as much feedback as possible. They should also answer any of their stakeholder’s questions.
- Attendees - Development Team, Scrum Master, Product Owner. Optionally, management, customers, developers, and other stakeholders.
- Timing - At the end of the sprint.
- Duration - In a one-week sprint, the Sprint Review lasts one hour.
- Agile framework - Scrum and Kanban. Kanban teams do these reviews after the team milestones, not sprints.
Outcomes
After this ceremony, the Product Owner might need to adjust or add to the product backlog. They might also release product functionality if it's already complete.
Top tips
- Schedule in time to rehearse before the meeting to help your team present with confidence, especially if external stakeholders are coming along.
- Don’t showcase incomplete work. Review your Sprint Planning and the original criteria if you’re not sure whether the work is complete.
- Besides product functionality, focus on user experience, customer value, and the delivered business value.
- Consider ways you can introduce a celebratory feel to acknowledge the team’s effort.
4. Sprint Retrospective
In this final scrum ceremony in the sequence, you look back on the work you’ve just done and identify ways to do things better next time. The Sprint Retrospective is a tool for risk mitigation in future sprints.
- Structure - The teams discuss what went well throughout the sprint and what went wrong. The Scrum Master should encourage the Development Team to speak up and share not only facts but also their feelings. The goal is to gather rapid feedback for continuous improvement in terms of process. It’s also an opportunity to emphasize good practices that the team adopted and should repeat.
- Attendees - Development Team, Scrum Master, Product Owner (optional).
- Timing - At the end of the sprint.
- Duration - 45 minutes per sprint week.
- Agile framework - Scrum and Kanban (occasionally).
Outcomes
After this session, the team should clearly understand the problems and the wins that happened throughout the iteration. Together, the group comes up with solutions and an action plan to prevent and identify process problems in the next sprint.
Top tips
- Focus on both facts and feelings
- Gather information that helps you focus on continuous improvement – this might include tools and relationships
- Be honest and encourage ideas that solve process-related problems
- Even if everything went well, have this meeting – retrospectives provide ongoing guidance for the next sprint.
"With the speed of change expected to continue, the need has never been greater for an operating model that keep up." - McKinsey
Agile lessons to live by
As a team of experienced agile practitioners, we’ve picked up some key learnings about what it takes to get the most out of your agile ceremonies and create the foundations of a truly agile organization.
Here are our top tips to make your ceremonies a success:
- Be deliberately present - During the ceremonies, remember to take moments to pause and remind yourself of why you’re there. Show others that you’re present by giving them full attention and using your body language. In a remote setting, angle your camera as though you’re sitting across from them, look into the lens regularly, and use a distraction-free background.
- Practice active listening - Think about what the person is saying, who they are, and what they need from you. Are they looking for a soundboard, do they need your help or opinion, or are they looking for an emotional connection?
- Understand motives - Understand the motivations of your teammates before speaking. Consider why they should care about what you’re saying by connecting your message with their own motivations. Provide context where possible to let them know why your message matters.
- Be flexible - It's important to remember that there is not a one size fits all approach to agile ways of working. What works for one team may not work for another, so you need to experiment to find out what works then tailor processes to suit your team's needs.
- Create cultural alignment - The best processes in the world won’t deliver what you need if you don’t have the culture to support their delivery. Agile ceremonies need to be supported by a culture where people are actively engaged, confident to raise issues, and value continuous improvement.
Agile ceremonies lead to better results
While it can take time for teams new to agile to adjust to agile ceremonies, they are worth the effort. By providing a clear structure and achievable outcomes, they help align everyone on the product, communication, and priorities.
The result? Agile teams that provide better quality products faster – and deliver real business outcomes.
Wherever your organization is on your agile journey, it’s worth keeping in mind that each team and each suite of products are different, so there’s no standard recipe for success. The good news is that by working within the continuous improvement mindset the agile framework promotes; you too can iterate and improve your agile ceremonies over time.
Ready to get started?
Easy Agile TeamRhythm supports your team's agile practices in Jira. Supporting your team from planning right through to retrospective, TeamRhythm helps you and your team work better together to deliver value to your customers.
Features include:
- Agile sprint and version planning tool - Planning is quick and easy when you create and estimate issues on the story map. View your work under initiatives and epics, and see swimlane stats at a glance, ensuring team capacity is filled but not overcommitted
- Agile story mapping - Map the customer journey using initiatives, epics, and stories alongside your agile Jira boards. Quickly and easily add new or existing stories inside the story map. Drag and drop to prioritize by value to the customer.
- Product backlog refinement - Escape your flat backlog and view your work on the story map matrix. Drag and drop issues to prioritize or schedule. Quickly update story summaries and story point estimates with inline editing for a better backlog.
- Team retrospectives - Celebrate success, gain insights, and share learnings with team retrospective boards for scrum and kanban, encouraging collaboration and transparency, so you and your team are continuously improving.
WorkflowAgile 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.