Retrospectives

High-performing agile teams thrive on adaptability, collaboration, and continuous improvement. But for learning to truly happen, teams need psychological safety—a culture where people feel comfortable speaking up, sharing ideas, and acknowledging failures without fear of judgment. One of the most overlooked aspects of team inclusion in agile team dynamics is how people learn. Not everyone processes information the same way, and understanding diverse learning styles can help create environments where all team members feel supported, engaged, and empowered to contribute.

Want to find out your specific learning preferences? Download your free Learning Style Quiz and Guide on how each learner type absorbs knowledge best.

Understanding Learning Styles and Learner Types

Think of a time you learned something quickly and effectively, and try to pinpoint what made it work for you. If it was a learning experience you enjoyed and found useful, the way the information was presented was probably well aligned with the way your brain likes to process new knowledge. For some people, that might look like videos, or a chance to practice and apply, or having time to read and take notes down.

Understanding your own learner type and how you best process information will improve your self-awareness at work, enabling you to learn more effectively and advocate for your learning needs.

But why is it important to understand the learner types of those around you?

• Team awareness → Adapt to others, improve team collaboration and inclusion
• Leaders & trainers → Support diverse learners, create accessible environments
• Inclusion → Recognizing and valuing different ways people process information and communicate
• Psychological safety → People learn best when they feel safe to ask, experiment and fail

Before we get into looking at the four learning styles, let’s take a moment to recognize that learning preferences aren’t one-size-fits-all—many people have a mix of preferences and may not fit neatly into just one category. Diverse learners—those who process, absorb, and express knowledge in different ways—benefit from flexible approaches, and may align with more than one learning style, parts of a few, or none at all. Neurodiversity in the workplace is an important consideration here—neurodivergent individuals often have unique information processing styles and may need additional support to ensure they can engage effectively. The key is to find what works best for you and create an environment where everyone can learn in their own way.

The VARK Learning Model: Four Learner Types

The VARK learning model categorizes learners into four main types:

Psychological Safety & Team Inclusion in Agile

Now that you understand your own learning style—and that others may learn very differently—let’s talk about how this contributes to team effectiveness.

Learning, growth, and innovation are cornerstones of high-performing agile teams, but these things don’t happen in isolation. They can really only happen in environments where people feel safe to ask questions, experiment, and share ideas. It is well known that a key factor of successful and effective agile teams is their positive, healthy culture, and this is where psychological safety and inclusion come in.

Psychological safety and inclusion are essential for agile teams because they:

• enable people to learn and grow
• help teams adapt and change quickly
• reduce fear of failure, leading to innovation
• prevent misalignment and financial loss due to fear of speaking up

Inclusion and psychological safety aren’t just ‘nice to have’ - they make agile work.

➡️ What is inclusion?

Ensuring that everyone, regardless of background, identity, or learning style, has equal opportunity to contribute, feel valued, and thrive in a team or workplace.

How to foster inclusion in the workplace:

• Adapt communication and learning approaches to support different learner types.
• Create accessible ways for everyone to engage e.g. visuals, discussions, written formats, hands-on activities.
• Actively seek out and respect different perspectives in meetings, planning, and decision-making.
• Ensure all voices are heard by structuring discussions to prevent dominant voices from taking over.

➡️ What is psychological safety?

A team environment where individuals feel safe to speak up, take risks, ask questions, and share ideas without fear of judgment, rejection, or punishment.

How to build psychological safety in the workplace:

• Normalize giving and receiving feedback in a constructive, blame-free way.
• Encourage curiosity—frame mistakes as learning opportunities rather than failures.
• Leaders should model vulnerability by admitting when they don’t have all the answers.
• Create a culture where all input is valued by acknowledging contributions, even if they aren’t implemented.

Agility is a learning process

The strongest agile teams learn, adapt, and have a culture of continuous improvement. Psychological safety enables teams to ask questions, challenge ideas, and experiment without fear - key to fast and effective feedback mechanisms.

Why psychological safety matters for all learners…

People process information differently—safe environments let all learners express needs, engage in their way, and contribute fully. Diverse learners, including neurodivergent team members, may not fit one learning type—psychological safety ensures they can ask for what they need without judgment, and feel valued for the way they engage with and process information.

The impact on agility?

• Align: Safety fosters open discussion → better decisions, clear priorities.
• Improve: Teams feel safe to experiment → faster learning, better solutions.
• Inform: Feedback flows freely → smarter investment decisions, stronger adaptability.

What does this look like in practice?

Retrospectives: The Ultimate Learning & Inclusion Space

Retrospectives are where Agile teams pause to reflect, learn, and improve. But for a retro to be effective, it must be psychologically safe and inclusive—because without trust, learning can’t happen.

So, what makes a retrospective psychologically safe and inclusive?

✅ All voices are heard → Everyone, regardless of communication or learning style, has a way to contribute.
✅ Blame-free reflection → The focus is on learning and improving, not pointing fingers.
✅ Actionable follow-through → The team sees real change as a result of their input, building trust.

How to Create Inclusive & Safe Retros

To ensure your retrospectives work for all learning styles, consider:

• Use multiple ways to gather input → Anonymous feedback, written reflections, open discussion, or interactive boards.
• Encourage different communication styles → Some may prefer speaking up in the moment, while others need time to process and write.
• Follow through on feedback → If teams don’t see changes happen, engagement will drop.

A great retro is not just a meeting—it’s a space for learning, collaboration, and trust-building. And the right tools can help.

How Easy Agile TeamRhythm Helps Agile Teams Run Inclusive, Psychologically Safe Retros

While Easy Agile TeamRhythm is a Jira app built for creating, estimating, and sequencing work at a team level on an interactive user story map, it is also a platform for running engaging and effective agile retrospectives. The retrospectives feature of Easy Agile TeamRhythm allows uses to create and track action items from retros by group feedback, identifying themes, and converting them into Jira issues for each planning. You can use templates, mood surveys, and timers to keep your ceremonies focused and effective.

Build collaboration and improve team alignment

Easy Agile TeamRhythm makes team retrospectives boards the hub for learning and improvement, allowing teams to celebrate wins, share learnings, and improve their team alignment and workflow. The ability to set privacy and permissions ensures that team information is only available to those your team trusts.

How Easy Agile TeamRhythm features create psychological safety and inclusion

Final thoughts

Inclusion and psychological safety aren’t just concepts—they’re the foundation of high-performing Agile teams. By recognizing different learning styles, creating space for all voices, and fostering a culture where people feel safe to learn and experiment, teams can truly thrive. What’s one thing you’ll do to make your Agile team more inclusive, supportive, and effective? Small changes can have a big impact.

Start building more inclusive, collaborative teams

Download your free copy of the Learning Style Quiz. Use it to gain lasting insights into how your team learns and works best.

Across hundreds of teams, we saw the same pattern: retrospectives were happening regularly, thoughtfully - and yet, less than half the retrospective action items ever got completed. Teams kept identifying valuable improvements, but those improvements stalled in execution. Instead of driving change, the same issues resurfaced sprint after sprint.

When we spoke with customers, they weren’t unclear on what to improve - they were actually stuck on how to follow through. The lack of visibility, accountability, and prioritization made progress feel out of reach.

That frustration led us to rethink how we approach retrospectives. Not just in the room, but in the days and weeks that follow. Because while most teams know how to reflect, far fewer know how to move forward.

Want to dive straight into action? Grab our free Retrospective Action Template here - a clear, practical guide to help your team stop spinning in circles and start making progress that actually sticks.

Or if you're keen to understand the deeper why behind this challenge, keep reading.

The invisible graveyard of good ideas

Think back to your last few retros. You likely surfaced blockers, celebrated wins, maybe even explored a tough team dynamic. The discussion probably felt honest - valuable, even.

Now ask yourself: What actually changed as a result?

Too often, retrospective action items, even the well-intentioned ones, are lost to the shuffle of a new sprint. The Jira board fills up, the deadline looms, and those carefully considered ideas fade into the background.

It’s not that teams don’t care. It’s that we often lack a system for taking action from team retrospectives in a way that’s trackable and integrated with our actual work.

We’ve seen the pattern: teams revisit the same problems retro after retro. Over time, that repetition chips away at trust. "Didn’t we already talk about this?" becomes the refrain, and eventually, the retro starts to feel like a ritual with no reward.

The follow-through problem

Most retrospectives don’t fail during the session itself; they falter in the days and weeks afterward. According to a poll in PMI's community, nearly two-thirds of respondents implemented fewer than 25% of the ideas from their retros - none reported implementing more than 75%.

"If your team consistently creates action items during Retrospectives but rarely completes them, you’re not alone. Unfinished action items are a major productivity killer and lead to stalled progress. The key to real improvement isn’t in creating long lists—it’s in following through. By treating Retrospective action items with the same importance as other Sprint tasks, your team can finally break the cycle of unfinished improvements and see real, beneficial change, individually and at the team level." - Stefan Wolpers, Age of Product

Follow-throughs often break down because of:

• Lack of clear ownership‍

When an action item belongs to 'everyone', it ends up belonging to no one. Teams that don’t assign a specific owner are less likely to see the item through. Accountability is a critical lever for ensuring follow-through and it’s often overlooked, especially in team-wide retros.

• No deadlines:

Action items without a timebox drift into the background. Teams frequently delay or deprioritize tasks that aren’t linked to specific sprint milestones or review points. Time-bound goals make follow-up tangible and measurable.

• Vague outcomes:

Teams often fall into the trap of writing retrospective items as intentions rather than actions. Broad phrases like “improve communication” or “fix our process” lack specificity. Without a clear 'what' and 'how', nothing moves.

• Too many actions:

When every idea from the retro becomes an action item, focus disappears. Prioritization is vital. Teams need to pick one or two meaningful improvements that are realistic for the sprint ahead. Otherwise, everything feels equally important—and nothing gets done.

• Poor visibility:

Action items are often scattered - living in whiteboards, static docs, or someone's memory. If teams can’t see what they committed to, they won’t act on it. Integrating follow-up tasks into the team’s daily tooling (like Easy Agile TeamRhythm in Jira) makes accountability unavoidable.

All of these factors add up to the same end result: a wide gap between good intentions and real progress. In our own usage data of Easy Agile TeamRhythm, teams were completing only 40–50% of their retrospective action items. After releasing features to surface and track incomplete actions, that completion rate jumped to 65%. Better follow-throughs, not just better conversations, are needed to drive real progress.

Common retrospective anti-patterns and their solutions

nti-patterns are common but counterproductive approaches to recurring problems that initially appear helpful but ultimately lead to negative outcomes. Unlike simple mistakes, anti-patterns are deceptive - they feel like the right thing to do in the moment but create deeper issues over time.

Teams consistently struggle with follow-through due to a combination of anti-patterns that weaken accountability and momentum. Here are the most common retrospective anti-patterns we see and how to address them:

1. The groundhog day pattern

Anti-pattern: The retrospective never changes in format, venue, or length, leading to the same issues being discussed repeatedly without resolution.

Why it happens: Teams fall into comfortable routines that feel "safe" but become stale and ineffective over time.

Solution: Vary your retrospective format regularly. Use different techniques like Start-Stop-Continue, 5 Whys, or Timeline Retrospectives. Change venues when possible - even moving from a conference room to an open space can shift energy and perspective.

2. The UNSMART action trap

Anti-pattern: Teams create action items that are vague, unmeasurable, or unrealistic (e.g., "improve communication" or "be more agile").

Why it happens: In the moment, broad aspirations feel meaningful, but they lack the specificity needed for execution.

Solution: Apply the SMART criteria to every action item: Specific, Measurable, Achievable, Relevant, Time-boxed. Instead of "improve communication," try "implement daily 15-minute team check-ins for the next two weeks."

3. The blame game

Anti-pattern: Retrospectives become cycles of finger-pointing and complaints without constructive problem-solving.

Why it happens: Teams lack psychological safety or facilitation skills to move from problems to solutions.

Solution: Establish "Vegas rules" (what's said in the room stays in the room) and focus on systems rather than individuals. Use techniques like "How might we..." questions to shift from blame to solution-oriented thinking.

4. The accountability vacuum

Anti-pattern: Action items are assigned to "everyone" or "the team," meaning no one feels personally responsible.

Why it happens: Teams want to avoid singling people out or assume collective ownership will naturally emerge.

Solution: Assign every action item to a specific person, even if execution involves the whole team. That person becomes the "champion" responsible for driving progress and reporting back.

5. The external focus trap

Anti-pattern: Teams spend most of their retrospective time discussing issues completely outside their control (other departments, management decisions, external dependencies).

Why it happens: External frustrations are often more emotionally charged and easier to discuss than internal team dynamics.

Solution: Use the "Circle of Influence" technique. Acknowledge external constraints briefly, then redirect focus to what the team can directly control and improve.

6. The documentation desert

Anti-pattern: No one takes notes or tracks what was discussed, leading to forgotten insights and repeated conversations.

Why it happens: Teams underestimate the value of retrospective outcomes or assume everyone will remember key points.

Solution: Designate a rotating note-taker and create a simple tracking system for action items. Include photos of boards or flip charts to capture visual elements.

7. The participation paradox

Anti-pattern: Some team members dominate discussions while others remain silent or disengaged.

Why it happens: Personality differences, power dynamics, or lack of structured facilitation create unequal speaking opportunities.

Solution: Use structured techniques like silent brainstorming, dot voting, or time-boxed speaking turns. Actively invite quieter members to share and ensure psychological safety for all voices.

A 5-step system for retros that lead to progress

Here’s the rhythm we’ve seen work across resilient, high-performing teams:

1. Prepare with purpose
   • Revisit action items from the previous retro - not just to tick them off, but to understand what’s changed since they were raised.
   • What moved forward? What didn’t? Why?
   • Clear out what’s stale. Highlight what’s still relevant. Identify patterns that deserve deeper discussion.
2. Focus the dialogue
   • Get beyond symptoms. Dig into root causes.
   • Use tools like “5 Whys” to sharpen your thinking.
   • Anchor the discussion on: What’s urgent and worth solving now?
3. Prioritize with intention
   • Don’t try to fix everything. Use an Impact/Effort Matrix to filter.
   • Choose 1–2 action items to commit to.
   • Assign owners. Define success. Agree on timelines.
4. Track where you work
   • Use a retrospective action tracker that lives inside your workflow.
   • In Easy Agile TeamRhythm, you can surface incomplete items, view their history, sort by relevance, and understand their context - all without switching tools.
5. Close the loop - every time
   • Review previous action items at the start of each retro.
   • Celebrate what’s done, even if it's small.
   • Reassess what to keep, modify, or drop.
6. Measure progress
   Start tracking your continuous improvement progress with simple, actionable metrics:Measuring these over time tells you whether you're improving how you improve.
   
   • ‍Action Item Completion Rate – % of action items completed before the next retro (target: 80–100%)‍
   • Recurring Issues Rate – How often the same topic resurfaces across retros‍
   • Average Age of Open Action Items – How long improvement tasks stay unresolved
   • ‍Retro Participation Rate – % of team actively contributing to retro inputs or votes

Stop repeating the same conversations

A team retrospective that works isn’t one that just uncovers issues - it’s one that resolves them. Building a habit of follow-through transforms retros from a passive meeting into a lever for real change.

If your retros feel like déjà vu, the problem might not be how you talk. It might be what happens after.

🎁 Get the full framework

We’ve distilled all these lessons and more into a practical, field-tested Retrospective Action Template. Inside, you’ll find:

• A step-by-step worksheet
• Guidance for assigning and tracking scrum action items
• Examples of achievable retrospective action items
• Built-in strategies for how to make a retrospective meaningful

👉 Download the free template here.

You’re already talking about what matters. Let’s make sure you act on it.

‍

When I first began working as a Scrum Master, I quickly became focused on the world of metrics. I believed that for my teams to succeed, they needed to have a continuously improving velocity, a stable cumulative flow diagram, or a perfect burn-down chart.

Sound familiar?

The problem with these metrics is that they are efficiency, not value focused.

It doesn't matter if a team builds one hundred new features rapidly if none of those actually deliver value to the customer. Efficiency metrics also have a habit of being misused and misunderstood, and this can breed malcontent.

Rather than focusing heavily on the data in retrospectives, I aim to focus on the people. The Agile Manifesto after all is about enabling people and their interactions.

Each of us are beating hearts behind our devices

Making time for human interaction...has resulted in far better outcomes than any beautifully constructed burndown chart.

Through embracing a human-first approach, a team I once worked with learned that they as a group were avid gamers. They'd been working together for years but hadn't known. This team was under a lot of pressure to deliver to difficult timescales and retros had fallen by the wayside.

This was the first thing I focused on; getting them believing in retrospectives again. Taking a human-centred approach, I melted the ice with some unfettered time to talk about non-work stuff “What was your favourite childhood video game”.

Just a few minutes of idle chatter about Sonic, Legend of Zelda, and Mario kicked off a chain of events that started with a few of them arranging to game together that evening, and before long, we had weekly video game-themed zoom backgrounds and retrospectives always had a gaming twist. Think Dungeons & Dragons, Tetris, Pokémon & Among Us.

Another great sign that a team is on the right track is how much they laugh together. This team was noticeably happier as a consequence, the change was drastic, almost tangible.

We aren't just avatars on our screens, each of us are beating hearts behind our devices, with passions, likes, dislikes, and aspirations. Making time for human interaction and building retrospectives that focus on our human side, has resulted in far better outcomes than any beautifully constructed burndown chart.

Why embrace a People-Centred approach?

Let’s delve a little into why you should focus on the human side. What’s in it for you?

• Increased Team Engagement and Participation: When retros are people-centered, team members will feel more connected to their colleagues, they’ll feel more comfortable actively participating, and have an increased sense of ownership of the team's successes and challenges.
• Improved psychological safety: With a people-centric approach, you can more easily create a safe and inclusive environment for team members to share their thoughts and experiences openly, without fear of judgement. This can foster a sense of belonging and increase the overall morale of the team.
• More enjoyment: We spend 8 of our waking hours working and half or more of our adult lives working. We owe it to ourselves to have a bit of fun in the process. A people-centric approach can result in people looking forwards to the next retro. More enjoyment, more engagement, and better outcomes. Simple.
• Better profitability: Oh, and it’s also better for the bottom line. A study by Gallup found a clear link between engagement and profitability in companies. Why are highly engaged teams more profitable? Teams that rank in the top 20% for engagement experience a 41% decrease in absenteeism and a 59% decrease in turnover. Engaged employees come to work with enthusiasm, focus, and energy.

The perfect conditions for continuous improvement.

Looking to get started with a few people-focused retrospectives?

Try a few of these free templates;

Psychological Safety Retro

The Aristotle project led by Google, found that the presence of psychological safety was the biggest factor in high performance for teams. Use this format to build the foundations of psychological safety with your teams, baseline the current levels and develop actions to improve.

Healthy Minds Retro

You wouldn’t let your car go without a service, and I bet your phone battery rarely goes below 10%. Why don’t we place the same focus on looking after our own needs, individually or collectively? Use this retro to narrow in on improvements that improve your team's health.

Spotify Health Check Retro

Famed for the agile framework that was never intended as a framework, some coaches at Spotify also released a team health check format which is great for measuring and visualising progress as a team. The simplicity of this format and its ability to highlight areas of focus as well as progress over time is particularly powerful. The best bit? It’s the team's perspective, not any external maturity model or arbitrary metric.

Autonomy, Mastery, Purpose Retro

Based upon the book ‘Drive’ by Dan Pink which highlighted the surprising things that motivate us, this retro helps teams to investigate the areas of their work which amplify or dampen our sense of autonomy, mastery & purpose. This book was a game changer for me and this retro could change the game for your teams.

5 Dysfunctions of a Team Retro

Another format based upon a highly acclaimed book, this retro builds upon the works of Patrick Lencioni and his 5 dysfunctions of a team. Using this retro, you can highlight the dysfunctional behaviours in your team and collectively solve those challenges together. One team, our problems, our solutions.

Let’s leave you with some things to think about

The key to unlocking the true potential of your teams lies in embracing a people-centered approach to retrospectives. By focusing on the human side of our teams, we can foster stronger connections, create a safe and inclusive environment, and ultimately drive better outcomes for both the team and the organization.

Remember, the Agile Manifesto is about enabling people and their interactions, and by placing people at the heart of our retrospectives, we can build stronger, happier, and more productive teams.

Forget about chasing the perfect metrics, and instead focus on building meaningful connections and fostering a culture of continuous improvement that is rooted in the human experience.

Retrospectives integrated with your work in Jira

Hoping to improve how your team is working together? Easy Agile TeamRhythm helps you turn insights into action, to improve how you’re working and make your next release better than the last.

TRY TEAMRHYTHM FREE FOR 30 DAYS

About Chris

For ten years now, Chris Stone has been fostering an environment of success for high-performing teams and organizations through the use of agility. He has worked across a wide range of industries and with some of the largest organizations in the world, as well as with smaller, lean enterprises.

​As The Virtual Agile coach, Chris intends to enable frictionless innovation, regardless of location, and is a firm believer in enabling agility whilst working virtually. Find him online at Virtually Agile >>

‍

Retrospectives help create an environment where team members can freely share their wins and challenges. By encouraging this feedback, you get critical insights into what can be improved in the next iteration. But while it sounds straightforward in theory, many teams struggle to make agile retrospectives work in practice.

So if we know team retrospectives can be a great way to drive continuous improvement and deliver value – why do so many teams struggle to get it right?

The slippery slope to becoming a tick box exercise

According to Easy Agile team member Tenille Hoppo, the struggle with retrospectives often lies behind two key challenges. "If you’re having the same discussions week after week, and the team can’t see anything changing, then people can become fatigued, disengaged, and bored," said Tenille. "Over time, retrospectives become less respected and less effective as a process, and eventually become nothing more than a tick box exercise".

"Then there’s the challenge around capturing actions in real-time," said Tenille. "We’ve all been guilty of having great ideas while working on something, but by the time the next retrospective comes around, the idea is gone".

The challenges around keeping retrospectives fresh, productive, and integrated with the work in Jira are behind the development of Easy Agile TeamRhythm, an app designed to overcome these common issues and help teams deliver value to their customers more quickly.

Integrating user story maps and retrospectives

"We believed if we could integrate the retrospective process right alongside the work in Jira, teams would be better able to deal with the issues blocking their progress and work more effectively," said Tenille. "So, we mapped out the groundwork as part of an Inception Week project, and soon after that, Easy Agile TeamRhythm was born".

Easy Agile TeamRhythm replaces our first app, Easy Agile User Story Maps, and integrates team user story maps with team retrospective boards. The user story maps are used for planning and managing work (including sprint planning and backlog refinement), while retrospective boards help teams do that work better. "It made sense to build on the sprint planning and backlog refinement capabilities of Easy Agile User Story Maps and introduce retrospective boards to capture and collate ideas for improvement," said Tenille. "With retrospectives colocated where work is managed in Jira, you can turn action items into Jira issues and schedule work, ensuring retrospectives are effective and valuable".

Elevating retrospectives with Easy Agile TeamRhythm

Easy Agile TeamRhythm supports teams from planning through to release and retrospectives. It covers user story mapping, sprint planning, version planning, backlog refinement, and team retrospectives.

By featuring a team retrospective board integrated alongside your Jira boards, agile teams can use the app to:

Capture feedback in real-time

Team members can capture feedback quickly and easily as they do their work. As a result, feedback and ideas don’t get lost and, instead, are there waiting for you when you run the next retrospective.

Combat fatigue with templates

You can access different templates to help change the format of retrospectives, frame things differently, and keep team members interested. This can also help teams see things from different angles and come up with new ideas.

Current templates include:

• Foundation
  A highly customizable template based on the Start, Stop, & Continue model. The team looks at looks at the actions they want to introduce, those that aren't working, and what can continue into the next cycle.
• Get Rhythm
  A music-themed template using the 4 L’s retrospective format, to understand what is “Loved, Learned, Loathed, and Longed for”. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of.
• Space Mission
  A stellar-themed template based on the Sailboat retrospective format, examining the approaches that inhibit progress, or reap desirable outcomes, and establish a direction for planning the next iteration.
• Rose Blossom
  A rose-themed template based on the Starfish model, that involves rating the efficacy of action items to determine the methodologies they should keep, discard, and apply in the next round.

Improve the next iteration by applying insights

The ‘Actions’ column is where you turn feedback into tangible actions and create in-built accountability. In just two clicks, you can turn an action item into a Jira issue that is automatically added to your backlog. You can then assign an owner and schedule it into an upcoming sprint or release.

“We’ve improved our communication and team alignment, which has helped give us faster results”.

Casey Flynn, Adidas

Make your next release better

"Agile isn’t about wringing every ounce of work you can get from your team, and it’s also not about wasting time in unproductive meetings that don’t drive an outcome," said Tenille. "With Easy Agile TeamRhythm, we provide the framework and functionality to help share learnings, plan solutions, and take action. And as teams focus on incremental improvements, they can start working better together, feel happier in their role, and deliver better outcomes".

TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS

Like to hear more?

Tenille presented on this topic in a webinar with Atlassian Solution Partner Almarise. Watch the full presentation below.

‍

The retrospective is a critical part of the agile process, providing an outlet for teams to discuss how they can improve. A sprint retrospective comes at the end of each sprint and offers the team an opportunity to assess their processes.

What went well? What didn’t go so well? What does the team need to do to improve next time? Agile is all about learning and iterating. Every time you complete a sprint, there are lessons to be learned. Agile continually takes what a team learns — the good, the bad, and the bland — and turns those experiences into actionable improvements.

This post will dig into sprint retrospectives, including the benefits, how they fit within the Scrum process, how to run an effective sprint retrospective meeting, and common mistakes to avoid.

The purpose of the sprint retrospective

The sprint retrospective is a dedicated time for team discussion. The time is allotted at the end of each sprint so that all team members can examine what went well and what needs to change. It’s all part of the greater agile methodology of continually improving your processes as you learn more. There’s no one set way of doing things, and there’s always room to become more efficient and effective.

A sprint retrospective:

• Encourages a continuous improvement mindset
• Creates a safe space for sharing positive and constructive feedback
• Gives everyone on the team an opportunity to express thoughts, ideas, and experiences
• Provides feedback in real-time after each sprint
• Brings the team together around common goals
• Exposes any issues from the previous sprint that are holding the team back
• Informs leadership of success and potential roadblocks
• Helps product owners make decisions for the next sprint planning
• Sets the team on a positive path for moving into the next sprint

How the sprint retrospective fits within the Scrum process

The type of retrospective you hold depends on the type of sprint or agile methodology your team practices. One of the most common methodologies in software development is the Scrum framework.

A Scrum team has three types of roles:

• Product Owner
• Scrum Master
• Development team

At the beginning of each Scrum, the product owner decides which items from the overall product backlog are moved to the sprint backlog to be completed over the upcoming 2-4 week sprint. The exact sprint timeframe is set in advance.

The Scrum is made up of four distinct ceremonies or events:

• Sprint planning
• Daily Scrum or stand-ups
• Sprint review
• Sprint retrospective

After planning is complete and the team knows which backlog items they are going to tackle for the current sprint, the work begins. The team checks in throughout the sprint via a daily scrum or stand-up meeting. This quick but essential check-in allows the Scrum team to discuss their progress and address any potential roadblocks on a daily basis.

The sprint review meeting takes place at the end of the sprint; it’s an opportunity for Scrum team members to showcase the work accomplished during the sprint. This could be an internal presentation or a more formal demo to stakeholders.

Last comes the incredibly important Scrum retrospective. During this time, the team can discuss what went well and what could be improved so the upcoming sprint can run more efficiently. Anything that’s learned along the way or discovered in the retrospective is brought into the next sprint planning session. This Scrum process repeats until there are no more product backlog items or the product is complete.

How to run an effective sprint retrospective meeting

The retrospective is a critical part of the agile process that should be treated with care and respect. Go in with a plan. Winging it might get you by, but everyone will get more out of the process if the person or people leading the retrospective is prepared.

Use our strategies below to run effective retrospectives that everyone looks forward to.

1. Ensure everyone’s voice is heard

The loudest voices in a sprint retrospective often get the most attention and speaking time, but they don’t necessarily have better insights than anyone else. Each person involved in the sprint process should be given an opportunity to speak.

If you find a few people are dominating the conversation or that some people never contribute, switch up your strategy to include everyone. Go around the room one by one with a question that each person needs to answer, such as “What do you think went well in this sprint?” or “What was your biggest challenge?”

2. Start, stop, continue

The 'Start, Stop, Continue' retrospective format can be expressed in many forms, but the general practice is the same. At the end of a sprint, you decide what you want to start doing, what you want to stop doing, and what you want to continue doing as you move into your next sprint. It’s a simple format that covers both what went well and what didn’t go so well.

Other versions of this exercise include the Rose Bud Thorn exercise, where participants share something positive, a budding opportunity, and a negative to improve upon. There’s also the Anchors and Sails exercise, where participants share what put wind in their sails (went well) and what anchored them down.

3. Establish specific action items

The retrospective is a waste of time if you don’t leave with specific action items. What is your team going to do about the issues brought up in the meeting? Ensure you keep track of the issues and the positive feedback people provide so that you can turn them into actionable tasks or goals before the meeting is complete.

You can’t implement absolutely every change that is brought up, but the discussion should give you a place to start. Work with the team to figure out what changes will provide the most impact. You can use an impact effort matrix or similar agile tools to make informed choices.

4. Retrospective the retrospective

Every now and again, take the time to review your retrospective. Ask for feedback from all team members on how the process could improve. What would make the experience easier on the team? What would they like to see implemented? What hasn’t been working during your recurring retros?

Wow, that’s getting a little meta, but it’s an important step. You need to continually assess your retrospective as well to make sure you’re getting the most out of the experience.

One thing to watch for: When people are bored, they engage less, which means it’s important to switch things up. You don’t want your retrospective process to run stagnant or lose its effectiveness.

5. Review action items at the next sprint retrospective

Make sure the hard work of your retrospective pays off. At the beginning of the next retrospective, take a small bit of time to review your previous action items. What goals and action items did you leave the last retrospective with? Did you accomplish what you set out to do, or do you still need to work at it?

Common retrospective mistakes to avoid

Avoid these common mistakes when running sprint retrospective meetings:

❌ Allowing a few people to dominate the conversation

❌ Not empowering softer voices

❌ Jumping to conclusions without a thorough discussion

❌ Asking the same questions over and over without mixing things up

❌ Forgetting about or not implementing the action items of the previous retrospective

❌ Skipping a retrospective due to lack of time or resources

❌ Forgetting about stakeholder and customer needs

❌ Failing to improve upon your retrospective process

Put your retrospective ideas into action with Easy Agile TeamRhythm

Sprint retrospectives help the entire team learn from each experience and improve. Doing them effectively means evaluating the retrospective itself, empowering voices, and listening to them.

We’re passionate about putting the needs of the customer first and foremost. Easy Agile builds products specifically designed for Jira users to help agile teams work more efficiently and effectively.

Easy Agile TeamRhythm supports the work of your agile team from planning right through to retrospective, encouraging continuous improvement so you're always getting better at what you do, and delivering better for your customers.

TRY EASY AGILE TEAMRHYTHM FOR FREE

One question that often arises is, “What are the indicators of a highly effective Scrum Master?" When striving to become an exceptional Scrum Master, consider the following:

• Identify Repeated Mistakes: While occasional mistakes are expected, it is important for the Scrum Master to collaborate with the team to identify recurring mistakes. By implementing policies and practices, the team can prevent these mistakes from happening again.
• Address Systemic Issues: If the team consistently encounters the same issues, the Scrum Master must recognize the presence of systemic problems. Working with the team, the Scrum Master can establish countermeasures to prevent these issues from reoccurring.
• Measure Improvements Over Time: Are we continuously improving as a team? Assess whether the team is more effective now compared to prior periods, such as 6, 9, and 12 months ago. Similarly, consider if the team will be better in the future. If progress stalls, it may be necessary to reevaluate the effectiveness of the Scrum Master.

If your team is progressing across all three of these areas, that’s a great sign that the Scrum Master is effective and that the team is learning and improving.

To drive continuous improvement, the Scrum Master should utilise the retrospective. The retrospective is a Scrum event conducted after the Sprint Review to evaluate and adapt the process and the team's ability to deliver products effectively. During this session, the Scrum Master guides the team in celebrating successes and exploring areas for improvement.

7-step checklist used by Scrum Masters during retrospectives to address problems:

1. Discuss the Problem: In the retrospective, the Scrum Master facilitates a discussion to identify the main challenges faced by the team.
2. Assess Impact: Determine the urgency and impact of the problem. Immediate action may be required for highly impactful issues, while less pressing matters can be addressed later.
3. Identify Root Causes: Understanding the root cause allows the team to gain deeper insights and generate potential solutions.
4. Generate Solutions: Once a significant problem is recognized, the Scrum Master guides the team in brainstorming solutions to address the issue.
5. Implement Solutions: This step is carried out in the subsequent retrospective. The Scrum Master ensures that the proposed solutions are tried and tested.
6. Evaluate Initial Results: Assess the effectiveness of the implemented solution. Did it fix the problem, make it worse, or have no effect?
7. Determine Next Steps: Based on the results, decide whether the problem is resolved or if further action is needed. This may involve continuing with the current solution or pivoting to a different approach.

For example, let's consider a team struggling with high defect rates. Their defect rates surpass both the organisation's average and industry standards. Here's how the 7-step checklist could be applied:

Step 1: In the retrospective, the Scrum Master raises the issue of high defect rates for discussion.

Step 2: The Product Owner shares feedback from the help desk team, highlighting customer complaints and the negative impact on sales.

Step 3: After deliberation, the team recognizes that many defects are missed during manual testing and identifies the lack of test automation as a contributing factor.

Step 4: A team member with experience in automated testing proposes implementing unit-level automated testing practices.

Step 5: In the subsequent retrospective, the team reports applying the new unit testing practices to all their work during the sprint.

Step 6: The team acknowledges that the automated tests identified six defects that would have otherwise been missed.

Step 7: The team agrees to continue using automated unit testing practices and plans to expand to integration-level testing as more of the codebase is covered.

By utilising this 7-step checklist, Scrum Masters can effectively leverage retrospectives to address recurring mistakes, resolve ongoing issues, and foster continuous growth and improvement within their teams.

If you have been running retrospectives for some time prior to 2020, you may be familiar with the follow agenda for a 1 hour session:

It is quite possible that as your team transitioned to working remotely from 2020 onwards, that retrospectives were still run in realtime but in a virtual setting using Zoom/Teams/Meet rather than in person.

Here at Easy Agile where we have flexible work arrangements, most team members usually spend 1-2 days a week in the office, though we now also have team members working interstate who are 100% work from home. As a result, all our teams really value their F2F meeting time whether it be in person or virtual, so we try to maximise that F2F time as much as we can for those important debates and conversations where the entire team can listen and participate in real time.

How Easy Agile uses TeamRhythm retrospectives to maximise team time

1. Team members can add items to the retrospective board anytime during the sprint

The team is reminded and encouraged to add items to the retrospective board at any time during the sprint, whenever it is top of mind. This can be done asynchronously without any time constraints. Items added like this tend to be worded better because it has not been rushed within the timebox of a traditional retro setting. Capturing the item when it’s top of mind ensures that these items are less likely to be forgotten when the team sits down together to run the retro at the end of the sprint.

2. The team self reviews the retro board during the sprint

The team can review the items on the retro board during the sprint and ping the author of a particular item if they are unclear as to the content of the item. With this feedback and over time, Easy Agile teams have learnt to write in a more specific manner where the item is less likely to be incorrectly understood.

3. Facilitators categorize items before the meeting

Grouping and sorting retro items during the meeting itself can often be a rushed and sometimes stressful event, especially if it is left to just the facilitator to do it while running the meeting at the same time. At Easy Agile, the nominated retro facilitator looks at the items of the board ahead of time and uses categories to label and group like-minded items together.

4. Face to face time are primarily for debate and action setting

Easy Agile retrospective meetings now mainly focus on reviewing and discussing those retrospective items already pre-labelled into specific categories, and deciding on what actions need to be taken in order to improve on future sprints.

The timing of a retrospective at Easy Agile now typically looks like this:

Wrapping it up

By encouraging the team to capture any lessons/thoughts they would like to share during the course of a sprint by capturing it as soon as it comes up on that sprint’s retro board, the majority of the time spent during the retrospective meeting at the close of a sprint focuses on meaningful conversations, ideation, candid feedback and debates and more thoughtful actions.
Less time is wasted with the team sitting silently trying to recall what worked or didn't work during the last two weeks and then having to type it out quickly and have it make sense to the rest of the team.

Just one more thing…

By the time you read this, we will have provided users with the ability to add items to a retrospective board directly from the Jira issue viewer, so now the friction to add a retrospective item is reduced by one less step.

And we also plan to provide the option to display any outstanding retrospective actions from previous sprints on the current retro board.

How do you and your teams run retros? Do you have any tips that you would like to share with us? We would love to learn from you as well. Please email us at hello@easyagile.com with subject: Retro tips.

You’ve come to the end of your sprint. Your team planned and prioritized the most important tasks and executed them as well as possible. It’s just almost time to begin planning again, and jump into the next sprint...

BUT — there’s a critical step you've overlooked.  The team retrospective meeting.  

What went well? What didn’t go well? What do you need to improve upon for next time?

We built this guide based on years of agile training and software development experience. Our ultimate guide to retrospectives has everything you need to run effective retrospective meetings, including the benefits of retrospectives, how to run them well, and extra resources.

An intro: what is agile?

But first, a review of agile. If you’re already familiar, feel free to skip ahead to the next section on retrospectives.

One of our favorite ways to differentiate the agile methodology from traditional, waterfall project management is to compare the approaches to jazz vs. classical music.

In classical music, a conductor brings a piece of music to an orchestra. The conductor guides the group through the piece, dictating exactly what happens where and when based on their own previously decided ideas. It’s a lot like traditional project management. A project manager creates a plan, brings it to their team, and tells them how to carry it out. Each step plays out as it was designed to, under the careful observation of the project leader.

Now, consider jazz music. Jazz is collaborative, with each bandmate feeding off of each other in a flexible environment. The band doesn’t go in completely blind. Everyone is working off of a piece of music — but it’s not strictly adhered to, allowing for new directions to be discovered in the moment. The band, just like an agile team, works together to create music flexibly and iteratively, with each iteration a little different — and hopefully even better — than the last.

💡 Learn more: Agile 101: A Beginner's Guide to Agile Methodology

Traditional project management isn’t flexible. Instead, team members must work in a sequential order that’s dictated by the original plan and project manager. Think of an assembly line. The same steps are followed from project to project. The linear structure means that if one piece of a project stalls, the entire project stalls.

Agile, on the other hand, is non-linear. It focuses on collaboration between team members, flexibility, and delivering consistent value to stakeholders throughout the development process. Each new iteration yields actionable insights about what’s working and what isn’t. This multidimensional way of working eliminates the bottlenecks and dependencies that are common with traditional project management.

What is a retrospective?

Retrospectives are a staple of many agile processes. They can be a critical moment for teams to come together and provide feedback about how processes can improve. Retrospectives keep the agile process — well — agile and encourage continuous improvement. No matter how well the last sprint went, there is always something that can be improved upon for the next iteration.

Agile retrospectives help agile teams gather data and feedback from those involved in the Scrum process. In Scrum, a retrospective is held at the end of every sprint, which is generally every two weeks. The retrospective is a chance for all team members to share what went well, what didn’t, and what could be improved upon for next time. The insights are taken into account in the next planning session to ensure teams learn from their mistakes, successes, and each other.

How retrospectives fit with Scrum

Retrospectives are conducted in a variety of agile methodologies, but for the purposes of our Retrospectives Guide, we’re going to discuss retrospectives within the Scrum process. It’s one of four critical meetings used in Scrum, coming at the conclusion of each sprint. So, how are retrospective meetings utilized in Scrum?

Scrum artifacts

Artifacts are the pieces of work the team completes over the course of the sprint. The product backlog is a compilation of tasks that the team believes need to get done in order to complete a product or iteration of a product. The product backlog is large and not very refined.

Items from the product backlog get moved into the sprint backlog when it’s time for them to be completed. The sprint backlog represents everything the team hopes to accomplish over one sprint, which generally lasts for two weeks. The sprint backlog is more refined — it focuses on the current state of the product, stakeholder feedback, and customer needs.

Scrum roles

There are three Scrum roles, and each has different duties within the Scrum framework. The product owner prioritizes the work that needs to be completed over the course of each sprint. They refine and prioritize backlog items, moving the necessary product backlog items into the sprint backlog.

The next role is the Scrum Master, who guides the team during the two week sprint, ensuring the Scrum framework is adhered to. This person is an expert in all things Scrum and can act as a facilitator during daily stand-ups and other important meetings. The Scrum Master tends to play a key role in leading retrospectives.

Lastly comes the development team. They make up the bulk of the team and complete the work set out in the sprint backlog. The development team participates in planning, attends daily stand-up meetings, and delivers work to the client and stakeholders.

Stakeholders and customers, while not directly on the Scrum team, play important roles in the Scrum process. Stakeholder and customer needs must always be at the forefront of development decisions. Stakeholders should be brought in early and often to provide critical feedback as a product is being developed.

Scrum ceremonies

The Scrum ceremonies are the events that take place within the Scrum framework. First comes sprint planning to set the stage, then daily Scrums or standup meetings, followed by a sprint review and a sprint retrospective.

The sprint planning meeting is when everything gets set up for the next sprint. Sprint planning meetings are opportunities to prioritize backlog items and get the entire team aligned on their goals for the upcoming two weeks. Without planning, the team won’t have clear goals, and they won’t know what tasks to tackle next.

The daily stand-up, sometimes called a daily Scrum, occurs every day of the sprint. The entire team participates in this daily meeting that updates everyone involved in the sprint. During the meeting, team members update each other on what they accomplished over the past 24 hours and what they hope to accomplish over the next 24 hours. This time also serves as an opportunity to discuss any issues that occurred or potential roadblocks that could prevent work from moving forward smoothly.

The sprint review meeting happens at the end of the sprint and is an opportunity to discuss the success of the sprint based on what tasks are considered “Done.” The sprint review can also bring stakeholders into the Scrum process to ensure everyone still aligns on where the product is going and what should happen next. Stakeholders provide invaluable insights that ensure the team stays on track to meet customer needs.

The last ceremony in the Scrum framework is the shining star in our guide. The sprint retrospective meeting arrives at the end of every sprint. It’s a critical meeting that helps the team improve from one sprint to the next. It allows team members to share what went well, what didn’t go so well, and what could be improved upon for next time.

We’ll dissect the elements of a good sprint retrospective throughout the rest of this guide.

💡 Learn more about the differences between these four meetings in our article: Agile Ceremonies: Your Guide to the Four Stages.

The benefits of retrospectives

Retrospectives put the iterative in agile. They provide a focused time for teams to learn from the past and each other so they can constantly improve the development process. Retrospective benefits are vast, and they trickle down into all areas of development. The insights from a retrospective can improve productivity, team dynamics, team trust, customer value, and the overall Scrum process.

Retrospective benefits include:

• Documenting feedback in real-time after each sprint
• Exposing issues from the previous sprint that are holding the product or team back
• Aligning the team around the most important issues
• Giving everyone involved an opportunity to express ideas, thoughts, and experiences
• Informing leadership of potential roadblocks
• Bringing the team together around common goals and action items
• Establishing a safe space for sharing positive and constructive feedback
• Encouraging a continuous improvement mindset
• Helping product owners make decisions for the next sprint
• Setting the team on a positive path for the next sprint

6 Effective retrospective techniques

Now that you know why retrospectives are so important to the agile process, it’s time to dig into how to run them effectively. Use our 7 retrospective techniques for a smooth meeting that keeps everyone engaged and always results in quality insights.

1. Choose a time that works for everyone and stick to it

It’s important that every member of the Scrum team participates in the retrospective. This means holding it when everyone is available, whether that’s in-person or virtually.

Get feedback from your team about the best time to set this meeting. It should take place right after the sprint ends but before the planning meeting for the next sprint. This can be a tight window, which is why it helps to schedule this meeting at the same time every two weeks.

Consistent meeting times help ensure the meeting actually happens and that an optimal number of team members can attend.

2. Find new and creative ways to acquire feedback

The Start, Stop, Continue format can take many forms, but the general process is the same. The team discusses what they want to start doing, what they want to stop doing, and what they want to continue doing in the next sprint. It’s a simple framework that addresses both what went well with the previous sprint and what could be improved for next time.

This is a tried and true method, but it’s also important to change up your format and ask different questions to keep the team engaged.

You are trying to acquire similar information each time (what to start, stop, and continue), but the way you gather that information can change and evolve. Add variety to your Scrum retrospective and mix things up every once in a while to keep everyone engaged.

Find new ways of asking similar questions, and bring in new ice-breakers that help the team feel comfortable discussing the past two weeks with honesty and clarity.

Other versions of “Start, Stop, Continue” include the Rose, Bud, Thorn exercise, where team members discuss something positive about the experience, a “budding” opportunity that can be expanded on for next time, and something negative about the experience that should be improved upon. Another alternative is the Anchors and Sails exercise. What about the last sprint weighed or anchored the team down, and what positives put wind in their sails, so to speak?

Boring retrospectives will make team members dread the meeting and will lower participation significantly. If participants aren’t engaged, they won’t contribute as openly, and they won't take ownership over the process.

Mixing things up is also a good way to uncover insights the team hasn’t considered before. New questions will spark new ideas, issues, and solutions that otherwise would not have been discovered.

3. Ensure all voices are heard

All voices need to be heard in the retrospective. It’s the responsibility of the meeting facilitators to make sure everyone has a chance to speak during the meeting and that loud or dominant personalities don't overtake the conversation. They have to be heard too, but not at the expense of more introverted team members.

If you notice some members of your team do not participate, start asking them direct questions. If this only makes them retreat further into their shell, take them aside at the end of the meeting for a one-on-one conversation. How can you make the meeting environment more comfortable for them? What will best enable them to collaborate effectively? Ensure this is framed in the right way so it doesn't sound like they're in trouble but rather like you value and appreciate their input.

4. Establish a comfortable environment

Ensure the retrospective feels safe and comfortable for everyone involved by instilling trust, collaboration, and open dialogue. Each team member should feel like their voice is important. It should be a place of positivity, not a chance for team members to dunk on one another. It’s up to the facilitator to ensure everyone is comfortable.

There should be room for everyone to speak. The whole team should feel like they can express their thoughts and opinions about what happened over the course of the sprint. If people feel uncomfortable or think their voice won't be appreciated or heard, they will hold back and not actually express their honest feedback.

This is detrimental to the process, as it can leave recurring issues to fester and worsen over the course of future sprints. It is in everyone’s best interest to be open and honest and to hear everyone out. The goal of a retrospective is to solve issues, prevent roadblocks, and improve the team’s processes. If team members are silent or dishonest about how they feel things are going, nothing will be solved.

Comfort plays a big role in how honest everyone will be. Ensure everyone is respectful and that speaking time is shared across the team. Take time building trust and allowing the team to get to know each other. A team that trusts one another can work together and build each other up — and you’ll be able to manage issues before they begin to hinder productivity, team wellness, or the Scrum process.

5. Document everything and create clear action items

If you don’t document it, it didn’t happen. Don’t rely on memory alone after the retrospective. Document the feedback team members provide, and ensure any important ideas or issues are brought to the next planning meeting.

Turn important insights into action items to make sure ideas are not lost. Ensure action items are specific and clear and that the whole team understands what “done” actually means for each task. Once an action item is created, make sure there is follow-up, ideally at the beginning of the next retrospective. Determine who is responsible for the action item and how important it is in the grand scheme of your product backlog.

6. Review your action items at the next retrospective

So, you’ve collected your and your team’s insights and made those insights into action items. The final step is addressing those action items during the next retrospective. Were they resolved, or did the same issues keep occurring?

It’s best practice to review your previous retrospective action items at the beginning of the next retro. Did the team make progress on the task? What else needs to happen? Do you need to follow up again at the next retrospective meeting?

What happens after the retrospective?

The retrospective may be the last meeting of the sprint, but it doesn't end there. Take those insights into the next sprint.

After the retrospective, the product owner reevaluates the product backlog and chooses what will go into the sprint backlog for the next round of work. They should consider past mistakes, successes, stakeholder feedback, and retrospective insights as they make decisions.

The sprint planning meeting comes after the retrospective and will help the team regroup and align on what they need to accomplish next. With each sprint, you will gain more information about the product, your customers, how the team works together, and your overall process. These lessons are taken into account to make improvements from sprint to sprint and product to product.

For better sprints, read our sprint planning guide, which includes everything you need to run efficient and effective planning meetings. ➡️ The Ultimate Agile Sprint Planning Guide.

Turn an action item into a Jira issue in just a few clicks, then schedule the work to ensure your ideas aren’t lost at the end of the retrospective.

Use Easy Agile TeamRhythm

LEARN MORE

Retrospective mistakes to avoid

Collecting feedback may sound simple, but there are many ways a retrospective can go wrong — from overpowering team members to asking repetitive questions to failing to capture insights effectively. Read our list of common retrospective mistakes to make sure your team doesn’t drop the ball.

❌ Skipping or delaying the retrospective

Due to a lack of time or resources, teams may consider skipping the retrospective. This is a costly mistake.

Do not, under any circumstances, skip a sprint retrospective. This is a critical time when the team has a chance to improve their processes. Skipping a retrospective enables the status quo and encourages complacency. The agile process is about continuous improvement — without the retrospective, you lose a critical opportunity to learn about the strengths and weaknesses of your team and its processes.

Delaying the retrospective can also be detrimental to your progress as a Scrum team. It’s important that you gather insights right after the sprint ends — while the ideas and issues are still fresh.

Delaying the retro could result in team members forgetting how the process actually went, leading to bland feedback that lacks the kind of detail that can create positive changes. And if delayed too long, something else could come up that takes priority over the retrospective, meaning the meeting may never occur at all.

❌ Always asking the same questions

The Scrum process is repetitive by nature, but that doesn’t mean your retrospectives should be boring or unbearably dry. Sticking to the status quo is a huge mistake in retrospectives.

When you repeat the same meeting every two weeks, you need to add variety in order to keep the team engaged. As soon as you lose team attention, engagement will drop, and the quality of the feedback you receive will too.

When running a retrospective, check in with yourself and the team to make sure engagement and interest stay high. If you are losing people’s attention and find engagement is dropping, change your format or the types of questions to keep everyone awake, attentive, and on their toes. Switching up who facilitates the meeting is another way to add variety into the mix.

❌ Allowing some of the group to dominate the conversation

Every voice on the team needs to be heard, but sometimes it’s the loudest ones that come through, well, the loudest. 📢 Effective retrospectives require multiple perspectives to deliver fresh insights.

Don’t let a select few voices dominate the conversation. A domineering team member will use all of the meeting’s time and limit the insights you can gather. If every voice isn’t heard, problems with the process could persist throughout multiple future sprints, severely impacting the effectiveness of your team. Plus, those who aren’t as loud will feel less involved and undervalued.

❌ Failing to empower softer voices

Along with discouraging domineering behavior, you need to amplify the softer voices.

Some people will be less likely to engage, or they may be too shy or afraid to express their opinions in a group setting. Watch out for this. If you notice it, find ways to make those underheard voices heard. It could mean asking them questions directly during the meeting, or it could mean taking a shy team member aside after the meeting to collect insights one-on-one.

If they find the group or your process intimidating, make the necessary adjustments to ensure everyone feels comfortable expressing their thoughts about the sprint. A retrospective is a collaborative process. Do what you can to engage and empower every member of the team.

❌ Jumping to conclusions without discussion

A single statement from one team member isn’t the end of the conversation. When team members bring up issues or ideas, they need to be discussed as a team. Do others feel the same way? Is it critical that this idea be implemented immediately, or can it be put on the back burner for now? How does a particular insight impact the product or customer needs specifically?

Don't jump to conclusions without having a meaningful discussion. You can gather information from your team quickly without throwing off your set meeting timeline. Don’t let any one topic throw you off course, but ensure you aren’t overlooking anything. If the team agrees an idea has merit, turn it into an action item that can be followed up on at the next retrospective meeting.

❌ Not implementing insights into the next sprint

Unfortunately, this is quite common. A team holds a retrospective meeting and does almost everything right only to fail to thoroughly record their team’s insights and put them into practice.

The whole point of the retrospective is to help your team improve. If you don’t properly document the feedback you receive from the team and don’t put those insights into action, you’re not getting the most from your retrospectives.

Turn feedback and discussion topics into clear action items you can follow up on later. Take important action items and insights into your sprint planning meeting and check in at your next retrospective. Were you able to make progress on the previous retrospective’s action items? What roadblocks did you hit? Do the action items require any further attention or follow-up?

❌ Not improving your retrospective process

Even a retrospective could use a retrospective! 🤯

Every now and again, take time to review your retrospective process. Ask your team to provide feedback on how they think the meetings are going. What do they like, what do they not like, and how do they think the retrospective meetings could improve?

You can improve on each aspect of your agile process. Go straight to the source to gather the opinions of those involved in the meeting. Do team members feel heard? Have issues been addressed to their satisfaction? Have the meetings grown stagnant?

When it comes to improving your retrospectives, your team has the data. Do not hesitate to ask.

Just because retrospectives come last in the Scrum process doesn’t mean they aren’t important. Don’t lose steam as you cross the finish line. Hold a retrospective at the end of every two-week sprint. Ensure each sprint retrospective includes insights from each team member and that insights are documented and transformed into clear action items.

📚 Additional resources

We have a wealth of free resources on the Easy Agile blog, and we continue to add to it every week. We recommend checking out our other guides as well as our top-performing agile content.

• The Ultimate Guide to PI Planning
• The Ultimate Guide to User Story Mapping
• Product Roadmaps: Your Guide To Why and How To Use Them
• The Difference Between a Flat Product Backlog and a User Story Map
• What's the Difference Between Kanban vs. Scrum?
• DEEP: The 4 Characteristics of a Good Product Backlog

Thanks for reading our ultimate retrospectives guide! 👏 If you have any questions about this guide, our other content, or Easy Agile products, reach out to our team. We love talking to teams and individuals about agile and how to work better together. We’ll continue to update this guide as we gain more retrospective insights, techniques, tools, and best practices.

Using Easy Agile to improve your Agile process

If your sprint retrospective isn’t effective, your next sprint will suffer from the same issues. It is imperative that Scrum teams gather at the end of each sprint to discuss what went well, what didn’t go so well, and what can be improved on for next time. Otherwise, you invite complacency and stagnation into your Scrum process — the antithesis of agile.

Improve your Retrospectives with Easy Agile TeamRhythm. The Retrospective features in TeamRhythm help your team stay on the path of continuous improvement. Watch the highlights tour to see how Easy Agile TeamRhythm makes sprint planning, managing your backlog, and team retrospectives easier. Visit Atlassian Marketplace to start your free, 30-day trial today.

Agile retrospectives are a time to reflect on the sprint before. During this time, the Scrum team decides on the agile retrospective template to use during retrospective meetings. A sprint retrospective template provides a structure for retrospective meetings. These retrospective templates guide agile teams in analyzing their previous sprint.

What is an agile retrospective?

Teams use agile retrospective meetings to improve the next sprint. As the team members move through the product life cycle, they gain new learning after each sprint retrospective, which they apply to the next sprint.

The focus of the sprint retrospective meeting

Sprint retrospective meetings ask four questions, as listed below. The agile team places these four questions in the four quadrants of their retrospective template. (Note: Team members can use a whiteboard or sticky notes to set up their meetings. Or they can use Jira software to facilitate remote team meetings in real-time.)

Co-located agile teams can also use whiteboards and sticky notes to do an agile retro. But for remote teams, agile retrospective template software allows all team members to participate in sprint meetings.

Here are the four question areas for discussion:

• What went as planned?
• Where could the team have made improvements?
• What should team members do in the next sprint?
• What confuses the team?

1. What went as planned?

The agile retrospective requires in-depth analysis. Team members can chat about what they enjoyed, which methodologies worked for them, and what agile ideas are worth taking into the next sprint.

Typical questions that agile teams ask in this first stage include:

• What were team members happy with?
• What actions delivered positive results?
• What processes or actions should the agile team continue with?
• Should anyone receive a special thanks for their contribution?

2. How could the team have improved?

Stakeholders examine where they went wrong and try to find the root cause of the issues. Brainstorming involves what they could have tried previously, where improvements are needed, and what processes or actions they can test in the next sprint.

Here are some ways to make this question more concrete:

• What has the team previously not tried that might work?
• What is one new thing that we could attempt?
• What new tactics or actions can we test next?

3. What should team members do in the next sprint?

In this part of the template, the team explores new ideas for how to improve their follow-up approach. New ideas can be risky, so the Scrum team should carefully consider opportunities for improvement. The idea in this questioning phase is to clarify problem areas, where value was not produced, and what was puzzling in the previous sprint.

In this round, the team should discuss:

• What didn’t work?
• What did the team do that did not produce value?
• Which areas specifically require improvements?
• What did not go as anticipated?
• What issues in the previous sprint are confusing?

4. What still confuses the team?

In this section, the team should focus on areas that weren’t as effective or did not go as anticipated and what areas need improving. Other relevant areas include where the agile team didn’t deliver value, focus areas that require development, and what was confusing about the sprint.

Here, it’s important to talk about:

• What questions still remain unanswered?
• What outcomes still require further investigation?
• Is the team following processes that don’t deliver clear value?

Through a process of iteration, the Scrum team brainstorm to come up with real-time solutions to take over to the next sprint. Using retrospective ideas, the team populates the four quadrants of the retro template, producing a visual representation of their post-mortem.

Scrum teams can apply the four questions above in other retrospective templates or customize a template to conduct their post-mortems.

Retrospective template options

Team members can choose from retrospective templates to customize their sprint meetings.

Sprint planning can benefit from any of the agile retrospective templates below:

• The start, stop, continue template
• The four Ls retrospective template
• A starfish retrospective
• Sailboat retrospective
• Glad, sad, mad
• Mad, sad, glad

1. Start, stop, continue

In the “start” part of this retro, the agile team looks at the actions they’ll take in the next sprint. “Stop” refers to looking at the recently completed sprint to examine what didn’t work and the actions that the team should no longer take. “Continue” means identifying what worked in the current sprint and should be taken over to the next cycle.

2. Four Ls

Agile teams use this retro template to understand what they “Loved, Learned, Loathed, and Longed for” at the end of the sprint iteration. The team calls out what they appreciate, what the sprint taught them, what went wrong, and what they would’ve wanted more of (coffee, team members, time, etc.).

3. Starfish

Instead of using a retro that focuses on what worked and what didn’t, the starfish highlights degrees of efficiency in deliverables. Teamwork involves rating action items as levels of effectiveness to determine what methodologies they should keep, discard, and apply in the next round.

4. Sailboat

Scrum teams use the sailboat retro to determine their trajectory in unknown waters. Applying the sailboat retro means knowing what approaches inhibit progress, what new approaches will reap desirable outcomes, and establishing a direction for sprint planning.

5. Mad, sad, glad

The mad, sad, glad sprint retrospective is a technique that concentrates on the emotional status of teams. Scrum teams ask each other questions to create positive emotional support. These questions are also aimed at morale-boosting to create a positive atmosphere that supports teamwork and continuous improvement.

The agile retro can follow any template they choose or select one and customize it for their specific needs. Whatever they do, teamwork is vital to the success of continuous improvement.

Decide on your retro template today

Now that you understand how the sprint retrospective template works, you can customize yours for joint teamwork.

Instead of focusing on longed-for outcomes and functionalities, Easy Agile can help your Scrum team move from sad to glad.

Team retrospectives right inside Jira

Looking to improve how your team is working together? Easy Agile TeamRhythm helps you turn insights into action with team retrospectives, to improve how you’re working and make your next release better than the last.

TRY EASY AGILE TEAMRHYTHM FREE FOR 30 DAYS

Psychological safety is the key to high-performing teams. But how is it created?

Agility is the response to a complicated situation where unknowns override the knowns. A high-performing team is one where all members have their say, and there are multiple decision-makers. Psychological safety is the belief that the workplace is safe for speaking up about ideas, concerns or even failures.

But where does kindness fit in?

Kindness is the foundation for psychological safety.

Kindness is essential at each of the first three stages of Dr Timothy R. Clark 4 Stages of Psychological Safety model.

Stage 1: Inclusion Safety

Humans long to feel accepted before they need to be heard. As a leader, you can create inclusion by showing kindness by being aware, sensitive and curious about an employee’s life. A good starting place is; how was your weekend? How is the family this week? Have you got any exciting celebrations coming up? You seem a bit quiet today, is everything okay?

Stage 2: Learner Safety

Humans need to ask questions, give and receive feedback, and make mistakes whilst feeling safe. Showing kindness creates the trust to do so.

Stage 3: Contributor Safety

Humans need to feel safe to participate as team members. A commitment to kindness ensures greater information flow, higher quality connections at work, and an increase in collaboration.

Individuals thrive in environments with psychological safety. Fear triggers the self-censoring instinct, holding us back. When the environment nurtures psychological safety, there is an increase in confidence, engagement, and high performance.

3 Tips for Implementing Kindness in Your Team Today

Tip 1: Model kindness yourself. No matter your role, kindness is contagious. If you start acting kindly, this will soon spread to your whole team. You can serve with kindness by listening, working with forgiveness, offering a helping hand, showing concern, or celebrating significant events in a coworker's life.

To celebrate random acts of kindness day and live our Give Back company value, our team donated to Kind Hearts Illawarra.

Tip 2: Incorporate kindness into your team's ceremonies. Each team member can say one thing they are grateful for in the morning huddle. Each ceremony can leave room to give thanks to a fellow team member. At Easy Agile, we put this into practice by encouraging everyone to share a 'good thing' each day.

Tip 3: Implement Good Thnx in your company Slack. The Good Thnx Foundation provides a link between people and corporates that want to give and charities. As our team send “thanks” to one another, the recipient is given $50 to donate to a charity of their choice. Our contribution via Good Thnx for FY21 was $15,201.

Simply put, be kind today; it is free and enables high-performing agile teams!

Agile retrospectives offer opportunities for introspection. As with many things in life, the end is almost as important as the beginning. That’s why it’s important to improve what went wrong throughout the iteration and repeat what went well.

The retrospective meeting should be held at regular intervals to analyze team processes and outcomes. Reflecting on the last sprint should help guide the next one.

Sprint retrospectives are also informal but structured. Informality is a typical characteristic of the retrospective meeting, which motivates problem-solving.

In this article, we’ll review what an agile retrospective is, how to lead it successfully, and how to use the retrospective format.

What is an agile retrospective?

An agile retrospective is also known as the sprint or sailboat retrospective.

The Scrum Guide provides a clear definition of the agile retrospective. The Guide says the agile team can use the sprint retrospective as an opportunity to gather rapid feedback for continuous improvement. Continuous improvement takes place through ongoing teamwork and work analysis.

During the meeting, the team discusses what went well and what didn’t. They should identify the good, that they will aim to repeat as well as the areas to adjust, so the next sprint can go more smoothly.

Here’s how the 12 principles of the Agile Manifesto describes retrospectives: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

How to implement a sprint retrospective format

You can either implement the agile retrospective after each sprint, quarter, or the entire project. However, you should have a retrospective at regular intervals to continue iteration and improvements.

Use a retrospective format for each meeting. Creating a retrospective board is a great place to start, it sets the scene for the team involved and they know exactly what is expected.

We've added retrospective boards to Easy Agile TeamRhythm to help you and your team through more of the agile cycle, from planning through to review.

Here’s how to plan the sprint retrospective:

1. Preparation

Like a standup meeting, your preparation time for the retrospective should take about 15 minutes. The retro is like a lean coffee meeting where the agenda is relatively unstructured but democratic. Everyone gets to contribute.

Ideally, you want to have a retrospective board where team members can capture feedback as it arises. Be sure to remind team members to add their thoughts to the board prior to the meeting.

The retrospective board helps guide the retro process through tasks where the team fell short or excelled with action items. It also helps to identify areas of improvement and the actions the group must apply to effect change.

If in-person team members don’t use software to facilitate their agile retrospective, they can use another technique. This technique usually involves a whiteboard, Post-Its, and markers to guide brainstorming throughout the meeting.

Whichever methodology (Scrum or Kanban) the scrum master uses, a visual representation helps facilitate the best possible outcomes for future workflows.

Hot tip 🔥

It is best to rope in a neutral facilitator or agile coach to guide this process. This technique should help encourage team members to participate and share without feeling pressured.

2. Use the retrospective template to guide your agenda format

The retrospective board helps direct the agenda for the meeting format. Whether you choose start, stop, continue, glad, sad, mad, or our team's personal favourite - high notes, low notes and keeping the beat. Make sure you customise it to suit your teams needs.

Typically, the process follows six steps:

2.1 Set the stage

Refresh your memory about themes and stories in the last sprint if necessary. Set a timer and give the team a little extra time to add any last minute thoughts or items that may be missing

At the start of the retrospective, the Scrum master should introduce the product owner, team members, and other relevant stakeholders.

Welcome everyone and let them know that their participation is valuable. Inform team members that honesty is critical in producing positive outcomes. Ensure new teams know that questions are welcome, and that sharing experiences is vital to a successful sprint retrospective.

Throw in an icebreaker to set the tone of the meeting. A brief game of “two truths and one lie” can quickly promote a relaxed atmosphere if you have enough time.

Let the team know the amount of time it should take to complete each section of the sprint review. To keep everyone on track, the timer can come in handy again here.

2.2 Celebrate the wins

Congratulate team members who excelled. Discuss posting success stories on LinkedIn or elsewhere before moving on with the sprint review. Interact with items made on the retro board, react with an emoji or leave a comment.

2.3 Gather data

Data gathering includes collecting information from team members about sprint retrospective problems. The purpose is for the team to uncover the root cause of the problems.

Team members begin this process by sharing sprint experiences. Whether the experience was good, bad, or ugly—share it. It’s always a good idea to capture how everyone is feeling, take a mood survey to understand the overall team feeling.

Share the processes you used and which milestones you accomplished. If team members applied new technologies, share how those went. If they used new tools, let everyone know the pros and cons of each tool. Whatever the experience, let everyone know what worked well and what was a disappointment.

The Scrum master can facilitate this phase by using the “five whys” methodology. The “five whys” essentially refers to asking why a problem occurred, five times. Repeating the question multiple times supports deep thinking to get to the root cause of the problem.

2.4 Brainstorm solutions

Once the team members identify the shortcomings of the previous sprint, they can brainstorm solutions.

The team meeting should now revolve around associations between problems and solutions. Linking problems and solutions involves understanding. Once the team understands their mistakes, they can brainstorm several solutions to fix each problem area with better action items.

Throw in as many ideas as possible to have several solutions for consideration. Once the team has alignment on the action item, be sure to capture this so the appropriate next steps can be taken.

The retrospective board in TeamRhythm sits alongside your work in Jira, so that retrospective items can be added as the sprint or version progresses. Action items from the retrospective can be turned into Jira issues so that items worth actioning aren’t lost at the end of the discussion.

The Scrum master should also ensure that the team has the authority to follow through with relevant solutions at this stage. If they don’t have the authority to solve problems, the Scrum master must bump the issue up to a higher level.

2.5 Select viable solutions

Not all solutions from the brainstorming phase will be viable — ask the Scrum team, including the product owner, to choose three promising solutions for each problem. You can use different techniques to narrow this process, and ask team members to vote. You might want to try a dot vote, or up vote by giving the solution a thumbs up.

The simple vote requires everyone to select the solution that resonates best with them in the follow-up activity. In the dot vote, meeting participants find the best three solutions by placing a dot on three of the ideas they believe hold the most value.

Lastly, the multiple vote system means that the scrum master gives everyone points. The scrum team must then give these points to one or more of the best ideas.

2.6 End the meeting

End the meeting on a positive note before continuing to the next sprint. Try to leave with:

• A detailed synopsis of the previous sprint
• A detailed sprint planning exercise for the next sprint meeting
• Clear action items and next steps
• Collaborate as a team to determine whether this outcome is effective or needs improvements for the next iteration

3. Sprint retrospective meeting outcomes

Software development teams can use the S.M.A.R.T. criteria to analyze their solutions. Getting the product owner's inputs is a valuable part of the retrospective meetings as they diversify priorities and perceptions

The agile coach or Scrum master takes the S.M.A.R.T. solutions and translates these into item actions. The Scrum master should ask team members to take responsibility for activities to promote ownership and encourage behavioral change.

Once the product owner agrees, each activity should then become part of the backlog.

How to achieve successful retrospectives from in-depth introspection

An in-depth introspection promotes continuous improvement and productivity. Following a retrospective template helps achieve these goals, while supporting integrated teamwork. The product owner also benefits from your team efforts with each sprint retrospective, which is a primary objective.

Gain team alignment with team retrospectives

Easy Agile TeamRhythm supports agile retrospectives, helping you and your team gain a shared understanding of the work, and how you work best together. Designed for Jira users, our goal is to help agile teams work together effectively.

Try Easy Agile TeamRhythm free for 30 days

Planning is a critical phase of the agile process; it's an opportunity to align on priorities as team and organize work in a sequence that will help it run smoothly. The planning process helps agile software development and other product development teams sort through new information, adapt to dependencies, and address evolving customer needs.

Agile is the opposite of traditional waterfall project planning, which takes a step-by-step approach. Waterfall has dominated project planning for many years, with detailed plans laid out at the beginning of a project that had to be adhered to rigidly. This may move a project or product forward, but it neglects to account for any new developments that could occur outside of the “master plan.”

Agile is an iterative process that helps teams reduce waste and maximize efficiency for the ultimate goal of bringing value to customers. This customer-first approach helps teams make informed choices throughout the development process — choices that continually and consistently provide value to stakeholders.

One of the greatest advantages of an iterative agile approach is that it enables early feedback from stakeholders. You don’t need to guess whether or not you’re making the right decisions — you can find out every step of the way by directly including stakeholders in your process. You can adapt your plan as you need to based on what will provide the most value to customers at any time.

Even if you are part of a seasoned agile team, there are always opportunities for improvement and processes to fine-tune. This post will outline some unproductive agile planning mistakes teams make, including how agile teams can avoid these common pitfalls.

Agile Planning Mistake #1: Not being on the same page as stakeholders

Do you involve stakeholders in your planning process? Do they understand your goals and why you are making each decision? Working directly with stakeholders, both internal stakeholders and the users of your product, will help you gain a clear view of both needs and constraints, and give you the information you need to determine what should be done when.

It's never a good idea to rest on assumptions. Your stakeholders live in a different world than the one you are deeply embedded in, with different priorities and assumptions of their own. So that you can produce deliverables that meet stakeholder expectations, you need to agree on what those expectations are. Involve your stakeholders in planning, but ensure everyone understands that expectations could evolve throughout the process based on new information gained from successes, failures, and customer responses.

Agile Planning Mistake #2: Not accounting for dependencies

Failing to account for dependencies in agile planning leads to bottlenecks, delayed releases, and undermines team collaboration. Collaboration within and across teams is needed for a business to deliver effectively. When multiple teams are working on interconnected features, if one team’s progress is blocked by another, the entire development cycle slows down. Without clear visibility of dependencies, work can be delayed and deadlines missed.

To minimize and avoid disruption to the flow of work, take the time to consult with stakeholders and anticipate dependencies early. Tools that help you visualise and map dependencies, and shared roadmaps to track cross-team dependencies, allow you to share an understanding of dependencies and sequence work in a way that avoids roadblocks. Proactively managing dependencies ensures smoother iterations, faster time-to-market, and a more predictable agile process.

Agile Planning Mistake #3: Using bland, flat product maps

Flat product backlogs are bland and boring 😴. Think carrot cake without icing. They lack the detail and functionality needed to realize the full story of your product backlog.

Plus, once you have more than a handful of items, they become overwhelming and difficult to organize in a meaningful way. It becomes less clear which item is the most important and more difficult to ensure your decisions align with the larger goal of the project.

When you plan out your roadmap, it needs context, and you must be able to clearly see the customer journey. User story maps visualize the customer journey in the planning process and throughout the entire process of product development. They utilize user stories — the smallest unit of work that can bring value to the customer — so you can plan and organize the backlog from the customer’s perspective.

📕 Read our ultimate guide to user story maps to learn more.

Agile Planning Mistake #4: Not allowing the plan to live, breathe, and adapt

As we've already discussed, agile is an iterative approach. This means your agile planning needs to leave room for changes. Your plan should be able to grow and adapt as you progress with each sprint or product roadmap.

At the beginning of a sprint, you lack the information needed to see the full picture. You don’t have everything you need to build the perfect solution, and that’s okay. It’s all part of the process. Spending hours or days trying to iron out the perfect plan just wastes time that could be better spent learning and solving problems as they come. What you thought would provide the most value during the planning phase could be completely different down the track.

You may need to alter your plan after a roadblock comes up in a daily stand-up, or you may learn about a customer concern that completely changes your direction. Iterations are inevitable and welcomed! They help you keep pace with incoming information as you learn from each other, stakeholders, and your customers.

Agile planning isn’t a promise. It’s an outline that will help you reach your goal, and that changes with your goals and circumstances.

Agile Planning Mistake #5: Not incorporating retrospective insights in the following planning session

Retrospectives are an essential piece of the agile process. They give teams a chance to reflect on everything that occurred in an individual sprint or after the completion of a product.

An effective retrospective asks the entire team key questions that can improve the process next time around. What went well? What’s worth repeating again? What didn’t go so well? What could be improved upon next time? What roadblocks or dependencies developed? What did you learn? How did you feel at the end of the sprint?

A retrospective provides insights that will improve efficiency, teamwork and team dynamics, the effectiveness of tools, and communication with stakeholders.

Simply holding a retrospective or collecting retrospective feedback is not enough to gain value. You need to ensure you’re incorporating the feedback into the following sprint planning meeting, and take action that leads to meaningful improvement. The next iteration will be all the better for the time you spend reflecting and improving based upon what you learned.

Agile Planning Mistake #6: Choosing tools that don’t take a customer-centric approach

Whether your team uses a Scrum process, kanban boards, or other agile methods, the tools you choose should always be customer-focused. And you need to continue using them in a way that keeps the customer at the forefront of decision making.

Teams can fall into a trap believing they’re focusing on the customer when they aren’t doing much of anything beyond following simple agile methods and generic processes. Customers need to be embedded in your development process right from the planning phase so that every decision a team member makes considers customer needs first.

Choose planning tools that help your entire team get to the heart of what makes your customers tick, and always check in to ensure you are making decisions in line with your customers.

For example, Personas provide a deep understanding of what customers want, need, don’t want, etc. They reveal key information about customer pain points, desires, demographics, goals, shopping patterns, and much more. We highly suggest developing customer Personas to get a rich picture of all the people who will use your product, but it’s not enough to just have Personas lying around.

You need to bring these Personas into your agile planning process and keep them front and center as you complete issues and continue to develop your product.