Retrospectives

TL;DR

Anti-patterns in agile feel familiar, but often quietly undermine progress. In this guide, we explore five common collaboration traps: large user stories, forgotten retro actions, superficial estimation, premature "done" labels, and ceremonial agility. You'll learn how to recognise, understand, and experiment your way out of them.

The Comfort Trap: Why Familiar Agile Habits Hold Teams Back

In agile, anti-patterns don’t announce themselves. They slip in quietly, posing as good practice, often endorsed by experience or habit. Over time, they become the default - until velocity stalls, engagement dips, and retros feel like re-runs.

In our conversations with seasoned coaches and practitioners across finance, government, consumer tech, and consultancy, we realised one thing - anti-patterns aren’t just a team-level concern. They signal deeper structural misalignments in how organisations think about work, feedback, and change.

To protect the privacy of our interviewees, we’ve anonymised company names and individual identities.

Let’s unpack a few of the most pervasive anti-patterns hiding in plain sight, and how to shift them without disrupting momentum.

1. The Giant User Story Illusion

Large User Stories: Oversized tasks that delay feedback and blur team accountability.

"It felt faster to define everything up front. Until we got stuck." - Product Manager, global consumer organisation

Large user stories promise simplicity: one place, one discussion, a broad view stakeholders can get behind. But when delivery starts, the cracks widen:

• Estimations become guesswork.
• Feedback loops stretch.
• Individual contribution becomes unclear.

In many teams, the difficulty isn’t about size alone - it’s about uncertainty. Stories that span multiple behaviours or outcomes often hide assumptions, making them harder to discuss, estimate, or split.

Symptoms

• Stories span multiple sprints.
• Teams lose clarity on progress and ownership.
• Estimation sessions are vague or rushed.

Root Causes

• Pressure to satisfy stakeholder demands quickly.
• Overconfidence in early solution design.
• Lack of shared criteria for 'ready to build'.

Remedy

‍Break stories down by effort, known risks, or team confidence. One team created their own estimation matrix based on effort, complexity, and familiarity—grounding pointing in delivery, not abstraction.

See also: The Ultimate Guide to User Story Mapping

2. Retro Amnesia: Action Items with No Memory

Incomplete Retro Actions: Items raised in retrospectives that quietly disappear, losing learning and team trust.

"We come up with great ideas in retros, but they disappear." - Agility Lead, multinational financial institution

When teams can’t see which actions carried forward, improvement becomes accidental. One coach described manually collecting and prioritising past action items in a Notepad file - because nothing in their tooling surfaced incomplete actions by default.

Worse still, valuable decisions get revisited unnecessarily. Teams forget what they tried and why.

Symptoms

• Recurring issues in retros.
• Incomplete actions vanish from view.
• Team energy for change drops over time.

Root Causes

• Retros run out of time before reviewing past items.
• No tooling or habit for tracking open actions.
• Actions lack owners or timeframes.

Remedy

‍Surface incomplete actions in one place and track progress over time. Revisit context: what triggered the decision? What outcome did we expect?=

3. Estimation Theatre: When Story Points Become Currency

Story Point Anchoring: The habit of assigning consistent points to avoid conflict, not to clarify effort.

"The team got used to anchoring around threes. Everything became a three." - Agile Coach, public sector agency

Story points should guide shared understanding, and not become a measure of performance or predictability. But many teams fall into habits:

• Anchoring to previous estimates.
• Avoiding conflict by picking the middle.
• Gaming velocity for perceived consistency.

Symptoms

• Homogeneous story sizes regardless of work type.
• Few debates or questions during pointing sessions.
• Velocity becomes the focus, not team clarity.

Root Causes

• Misuse of velocity as a performance metric.
• Comfort with consistency over conflict.
• Absence of shared understanding of story complexity.

Remedy

‍Reframe estimation as shared learning. Encourage healthy debate, try effort/risk matrices, and use voting to explore perspective gaps.

4. The "Done Means Done" Shortcut

False Completion: Marking items “done” when no meaningful progress was made.

"We mark items as done, even if we didn’t act on them." - Scrum Master, insurance and data services firm

Marking something "done" in order to move forward can feel pragmatic. But it hides reality. Was the issue resolved? Deferred? Invalidated?

Without clear signals, teams lose the ability to reflect truthfully on what’s working. One team described starting every retro with a conversation about what "done" actually meant, and adjusted their practices based on whether action was taken or just abandoned.

Symptoms

• Completed items have no real impact.
• Teams disagree on whether actions were truly resolved.
• Follow-up problems recur with no reflection.

Root Causes

• Ambiguity in what "done" means.
• Lack of closure or accountability for actions.
• Reluctance to acknowledge when something was dropped.

Remedy

‍Introduce a "no longer relevant" tag for actions. Start every retro by reviewing outcomes of previous actions, even if abandoned.

5. Anti-Patterns in Disguise: Agile vs Agile-Like

Ceremonial Agility: Teams follow agile rituals but avoid meaningful feedback, adaptation, or empowerment.

"We're agile. But we also push work through to meet delivery at all costs." - Project Manager, large enterprise tech team

Many teams operate in agile-like environments: sprints, boards, and standups, but decision-making remains top-down, and trade-offs go unspoken.

This hybrid approach isn't inherently bad - context matters. But when teams inherit agile ceremonies without agile values, collaboration becomes box-ticking, not problem-solving.

Symptoms

• Teams follow agile ceremonies but avoid real collaboration.
• Delivery decisions made outside of sprint reviews.
• Retrospectives focus only on team morale, not system change.

Root Causes

• Agile adoption driven by compliance, not culture.
• Delivery commitments override learning and adaptation.
• Leadership sees agile as a process, not a mindset.

Remedy

Is your agile framework enabling change - or disguising command-and-control? Use retros and sprint reviews to discuss system constraints. Ask what’s driving the way work flows, and who has the power to adjust it. Make trade-offs visible and shared.

Spot the Signs, Shape the Shift

Anti-patterns don’t mean your team is failing. They mean your team is learning. The most resilient teams are the ones that catch unhelpful habits early, and have the safety and support to try something else.

Retrospectives are the perfect place to surface them - as long as they’re structured for memory, not just reflection.

In the end, anti-patterns aren’t the enemy. Silence is.

Want to take action?

Try this in your next retro:

• Surface 1 anti-pattern the team has noticed (e.g. big stories, unfinished actions, silent standups).
• Ask: Why might this have emerged? What need did it originally serve?
• Run a one-sprint experiment to shift it. Keep it small.

The cost of anti-patterns isn’t just inefficiency. It’s losing the opportunity to get better, together.

Retrospectives were meant to be agile’s secret weapon.

In theory, they’re a dedicated space for teams to pause, reflect, and course-correct. A recurring moment of clarity in the blur of sprints. But in practice?

“We show up, we talk about the same problems, we say we’ll fix them... and then we don’t.”
- Jaclyn Smith, Senior Product Manager, Easy Agile

This isn’t just dysfunction. It’s disillusionment. And it’s costing agile teams more than they realise.

In this post, we dive into the hard truths explored by Jaclyn Smith, Senior Product Manager at Easy Agile, and Shane Raubenheimer, Agile Technical Consultant at Adaptavist in:

• 🎙️ Easy Agile Podcast Ep. 32: Why Retrospectives Fail & How to Fix Them
• 🎥 Webinar: Retro Action – Stop Talking, Start Doing
• 📝 The Action-Driven Retrospective Template

Our goal is not just to fix retrospectives, but to reclaim them. If that resonates with you, keep reading.

TL;DR:

• Retrospectives often fail because teams repeat surface-level issues without resolving root causes.
• Action items from retros are rarely followed up, leading to distrust and disengagement.
• The Action-Driven Retrospective Template helps teams focus on fewer, more impactful changes.
• Trust is rebuilt through consistency, accountability, and small wins that compound.
• Real improvement happens not during the retro, but in what the team does afterward.

When we stop believing that change is possible

The quiet failure of retrospectives doesn’t happen in a moment. It happens gradually, invisibly, over the course of sprints where insights are voiced but not acted on. When teams invest time in talking about problems, only to see them persist, they don’t just lose momentum. They lose hope.

In the podcast, Jaclyn Smith, Senior PM at Easy Agile, reflected on retros where participation seemed high, yet nothing stuck:

“We’d have these beautiful, well-facilitated boards. But when we checked in a sprint later, people couldn’t remember what the actions were. Or worse, they remembered, and knew nothing had happened.”

That erosion of trust isn’t always visible. But it’s felt. It manifests as disengagement, short answers, vague observations. When a team feels like retros won’t lead anywhere, they stop offering anything worth leading with.

This is the paradox of failed retros: the form persists, even as its function evaporates. The team is technically “doing the retro.” But the retro no longer does anything for the team.

Normalising dysfunction and agile anti-patterns

In the webinar, Shane and Jaclyn dissect this disillusionment based on their experience of working with hundreds of real teams across industries. Most teams can relate to this problem - they're doing everything “right”: regular standups, retrospectives on the calendar, a backlog that moves. And yet, they somehow feel stuck in the same spot.

That's because of one or more of these anti-patterns, which have become dangerously common:

• Cargo cult agile: Following agile rituals without purpose
• Hero culture: Over-reliance on a few individuals rather than teamwork
• Water-Scrum-Fall: Mixing methodologies without clear boundaries
• Team velocity misuse: Tracking productivity by team velocity alone
• Backlog noise: Long lists of tasks lacking customer value

The issue isn’t awareness. Teams know these patterns exist. What’s missing is a structure that interrupts them - consistently, visibly, and meaningfully.

“The worst retros aren’t chaotic. They’re quiet. No conflict. No depth. Just a board full of things we’ve already said.”
- Shane Raubenheimer, Agile Technical Consultant, Adaptavist

This is why retros don’t just need better facilitation. They need a redesigned relationship with action.

Building action into the ritual

The most fundamental problem Jaclyn and Shane identify is that retros end with “next steps”, but those steps never reappear. Actions get lost in Jira, or exist solely in a facilitator’s notes. They’re rarely revisited. They aren’t owned. And without ownership, there’s no accountability.

That’s why they created the Action-Driven Retrospective Template. It’s not flashy. But it forces a shift in rhythm:

• Every retro begins with last sprint’s actions. Were they completed? What impact did they have?
• Themes are not just grouped - they’re challenged. Why do they keep showing up? What’s beneath them?
• One or two actions are selected - no more. And they are immediately assigned, tracked, and made visible.

“This is about restoring integrity to the retro. If we’re not checking what we did last time, what does it say about what we’ll do this time?”
- Jaclyn Smith

The brilliance here is in the restraint. Rather than generate more insight, the template helps teams create follow-through - the most precious and elusive outcome of any retrospective.

Why teams need fewer actions and more outcomes

In agile culture, it’s easy to mistake motion for progress. A retro that generates 15 sticky notes and 5 action items might feel productive. But it often leads to diffusion of focus and quiet inaction.

Shane is blunt about this:

“I’d rather a team act on one thing really well, than half-act on five.”

The Action-Driven approach discourages long lists. It nudges teams to choose actions that are both impactful and doable within a sprint. It acknowledges capacity. It invites discernment. And in doing so, it cultivates trust.

Because when teams start seeing change happen, even in small ways, they begin to believe again. And belief, more than any tool or process, is what fuels sustainable agility.

Retrospectives as emotional reset, not just process audit

Perhaps the most refreshing part of the conversation was how emotionally honest it was. Neither Shane nor Jaclyn treated retrospectives as an abstract exercise. For them, it’s about what people feel when they leave the room.

“A retro should give people energy. It should help them see that we’re improving, that their voice matters, that something got better because of something they said.”
- Jaclyn Smith

This is what most guides miss. Retros aren’t just functional. They’re relational. They tell a story about whether the team can learn, grow, and improve together. When that story breaks, when people stop feeling heard, or stop seeing results, the damage goes beyond a missed task.

It touches morale. Culture. Confidence.

Tooling and rituals are not the answers, but the amplifiers

In the webinar, Jaclyn goes on to show how Easy Agile TeamRhythm can help teams carry retro actions directly into Jira workflows. It’s not about selling a tool, but rather about shortening the distance between reflection and execution.

Jaclyn’s point is clear:

“The retro isn’t where change happens. It’s where it begins. The real test is whether your sprint backlog tells the same story.”

This is where tooling earns its place - not by replacing conversations, but by preserving context and sustaining visibility. When actions from a retro are visible in the planning session, on the board, and during standup, they don’t disappear. They become culture.

Start with mindset shift. Then build the habit.

What makes this approach so effective is its humility. It doesn’t promise transformation. It promises traction.

Start with one action. Make it visible. Talk about it next time. Build a habit. Trust the compounding effect of small, completed improvements.

“Agile isn’t about doing more. It’s about doing what matters - better, and more often.”
- Shane Raubenheimer

If your retrospectives feel tired, you don’t need a new format. You need a new relationship to action.

And that begins not with a workshop, but with a single, honest question:

“What did we change last sprint, and did it make anything better?”

If you don’t know the answer, start here:

📝 Download the Action-Driven Retrospective Template
🎧 Listen to the full podcast
🎥 Watch the full webinar

You don’t need to fix everything this sprint.

You just need to prove, to your team, and to yourself, that change is possible again.

Collaboration in large-scale organisations often reveals friction in places teams expect to run smoothly. As product and development functions scale, the number of moving parts increases. So does the risk of misalignment.

At Easy Agile, conversations with our customers frequently surface familiar challenges. While each organisation is unique, the core struggles of collaboration are shared. To protect the privacy of the teams we spoke to, we’ve anonymised all quotes. But every insight is real, direct from the people doing the work.

This post is for anyone navigating the complexity of scaled collaboration, whether you're leading a team or working within one. Sometimes the hardest part is seeing the problem clearly. These are the patterns teams are running into, the questions they’re wrestling with, and the cracks that emerge when planning, alignment, and communication break down. Understanding and acknowledging these issues is the first step toward solving them.

Here’s what teams are experiencing and the key questions they’re grappling with as they scale collaboration.

TL;DR – Common collaboration challenges in scale-ups and enterprises:

• Teams struggle with communication and alignment, especially when working across multiple teams or departments
• Managing cross-team dependencies is a significant challenge, often causing delays and requiring frequent coordination
• Capacity planning and skill allocation are difficult, particularly when teams have to balance project work with ongoing operational tasks
• Teams face challenges in breaking down work effectively and maintaining visibility of progress across different teams
• Frequent changes in priorities and scope creep disrupt team planning and execution
• There are difficulties in translating high-level strategy into actionable team priorities and objectives
• Teams struggle with effective retrospectives and continuous improvement processes

What breaks down in cross-team communication?

Communication challenges tend to intensify with scale. As soon as multiple teams are involved, misalignment becomes more likely. A Senior Product Manager from a global HR tech firm described a pattern many teams will recognise:

"One of the main themes I heard in conversations with leadership was the lack of process, transparency, visibility, and dependency tracking. It’s always been manual across teams. We’ve done a really good job, but there’s an opportunity to do better."

Another team member highlighted how this disconnect tends to grow over time:

"At the start of each quarter, our conversations are strategic and cross-functional, involving sales and strategy teams. But as we dive deeper into execution, communication shrinks down to daily engineering huddles, and essential alignment details often get lost."

The problem isn't a lack of communication, but rather a shift in its focus. When delivery takes centre stage, strategic context gets sidelined. When teams move into execution mode, that shift in communication cadence creates blind spots across departments, leading to confusion, duplicated work, or misaligned outputs.

Why is managing dependencies across teams so difficult?

Dependencies create friction when they aren’t visible or clearly owned. Coordination across teams can be derailed by unclear sequencing, late handovers, or competing timelines. An Agile Coach at a financial institution shared:

"We had to run bi-weekly cross-program dependency calls just to stay on top of what was blocking who. We just list dependencies manually, there isn’t any unified visibility. At the ART level, it’s a mix of RTEs, Scrum Masters, and team members trying to link things, but beyond that, it falls apart"

A delivery leader at a global credit bureau reinforced the limitations of existing tools:

"I’ve never successfully been able to really tackle dependency visualization and put a process around that. It's always been manual. When I'm speaking to an executive, that means something... But when I'm speaking to someone on an agile team, it changes as it rolls up...Without proper plugins, even a robust tool like Jira struggles to provide clear dependency visuals. Planning becomes complicated quickly, leaving teams stuck."

Dependency risk increases when shared work isn’t tracked or visualised in a way that’s accessible to all stakeholders. Teams need to see not just their own work, but how it connects with others. Teams need more than awareness - they need shared visibility, clarity on ownership, and consistent ways to plan around dependencies.

How do teams manage capacity when demands keep shifting?

Planning team capacity isn’t just about headcount, but also about competing demands. Teams are often asked to deliver roadmap initiatives while supporting legacy systems, resolving production issues, or addressing technical debt. A product leader from a cybersecurity company shared:

"We’re always trying to achieve a lot with limited resources, and it makes roadmapping really difficult. We’ve made progress in estimating the team's bandwidth more accurately by looking at what they actually delivered last quarter. But we still hit the same issue - too many topics, too little time."

Another team shared how they introduced tighter prioritisation controls using a third-party tool, but even rigid structures have their limits:

"We use XXX as a source of truth for prioritisation. We have around 80 different initiatives prioritised from 1 to 80 of importance... no meeting can be scheduled if the project is not approved in the tool."

This helped formalise approvals and reduce noise, but it also revealed a deeper issue. Even with a strict gating process, the volume of initiatives stayed high, and prioritisation alone couldn’t solve for limited capacity. Clearer structures don’t automatically reduce the demand on teams or ease delivery expectations. That tension persists unless strategic scope is also narrowed.

What makes work breakdown and visibility so hard to maintain?

Breaking down initiatives into independent, testable stories is not always straightforward, especially when scope is uncertain or spans months. A software engineer working across multiple teams explained:

"Breaking work down is hard - some teams still think in layers. They say, ‘This only delivers value when the whole thing’s done.’ On top of that, we often run big planning in a five-hour day or stretch it awkwardly over two days. Third parties and shared services don’t get folded into teams, which makes breakdown and clarity harder."

Large epics often outlive the context in which they were created. As scope evolves, teams may struggle to maintain clear acceptance criteria and shared understanding.

An Agile Coach reinforced how hard it is to keep sight of progress:

"We break each story into smaller pieces as much as possible where it's testable by itself so the testing team can test it... But if it’s a lengthy project, spanning more than two months, it’s easy to lose clarity and effectiveness...Consistently tracking actions across multiple sprints involves endless toggling. It's difficult to quickly understand what's truly improving and what’s still stuck."

As work grows more complex, clarity suffers. Without reliable visibility, work risks stalling or repeating unnecessarily. Teams need tools, systems, and shared language to ensure breakdowns don’t get lost in the shuffle and progress remains meaningful.

Why do changing priorities and scope creep derail plans?

Frequent priority changes and scope creep disrupt planning discipline. They often signal deeper issues: vague goals, shifting leadership expectations, or unclear ownership. One product leader summed it up:

"Priorities used to switch constantly - sometimes halfway through a project, we’d have 30% done and then get pulled into something else. That context-switching really hurts. It demoralises engineers who were already deep into a feature. We had to raise it in a full engineering and product retrospective just to get some stability."

Another shared the toll it takes on delivery teams:

"We often found ourselves mid-quarter pivoting to newly emerging business needs, without fully aligning on what gets dropped. That lack of clarity meant engineers felt whiplash, and team goals kept shifting."

Without stable anchors in the form of clear goals and boundaries, even well-planned work can unravel. Work, then, expands to fill the available sprint, regardless of long-term impact, which brings us to the next challenge.

What stops teams from aligning strategy to daily work?

Teams need clear goals. But clarity breaks down when strategic objectives are too broad or when every team interprets them differently. A senior product manager explained:

"Prioritisation is only as good as your strategy, and ours wasn’t clear. The business goal was just ‘grow revenue,’ but what does that mean? Acquisition? Retention? Everyone wrote their own product objectives. It became a bit of a free-for-all. When goals are vague, it’s hard to prioritise work that ladders up to anything concrete."

Another added:

"We all set objectives tied to broad company goals, but when those goals lack precision, our objectives become misaligned, making prioritisation difficult and often inconsistent."

Without alignment between leadership priorities and team-level execution, valuable work can feel directionless. Objectives become outputs rather than outcomes.

What holds back meaningful retrospectives?

Retrospectives are intended to surface learning. But without consistent follow-through, they risk becoming routine. One Agile Coach shared how to keep them practical:

"We’ve tried tools where you just send a link and everyone rates how hard it was to get something done. But too often, it ends up with one person speaking and everyone else just agreeing. We’re trying to avoid the loudest voice dominating the retro. It’s still a challenge to get real, reflective conversations."

Another shared the risk of retro fatigue:

"To track action items consistently isn't easy... I have to toggle down and look at each one, which can make things cumbersome when ensuring certain behaviours have stuck...Effective retrospectives should surface recurring issues, not just review the recent past. Discussing ongoing challenges helps teams proactively tackle problems and move forward."

The barrier is rarely the ceremony - it’s the follow-up. Teams need lightweight ways to track retro actions, validate changes, and revisit unresolved pain points.

Where to focus

Improving collaboration means addressing the systems and habits that hold teams back:

• Keep strategic conversations active, not just at quarterly planning.
• Visualise and track cross-team dependencies clearly.
• Protect capacity for both roadmap work and operational stability.
• Break work into testable, clearly defined pieces.
• Reinforce the connection between business goals and delivery priorities.
• Make retrospective actions visible and measurable.

The teams we speak to aren’t struggling because they lack process. They’re navigating complexity. The opportunity lies in simplifying where it matters and supporting teams with the clarity to make progress, together.

The first step is recognising these patterns and giving them language. When teams can see and name the problem, they’re already on the path to solving it.

How Easy Agile can help

Whether you're dealing with blurred dependencies, vague objectives or sprint volatility, Easy Agile offers three purpose-built solutions to help teams stay aligned:

• Easy Agile Programs brings structure and visibility to cross-team planning in Jira. Perfect for managing dependencies and long-range planning across multiple teams and projects.
• Easy Agile Roadmaps gives every team a simple, shared timeline view, so they can prioritise and sequence work with strategic context.
• Easy Agile TeamRhythm makes sprint planning, story mapping, and retrospectives more engaging and purposeful, turning agile ceremonies into actionable, team-owned progress.

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