Sprint Retrospectives: Techniques and Steps to Run

Nishil Patel

Nishil Patel

Feb 5, 2025

7 min read

Share

Sprint Retrospectives: Techniques and Steps to Run

Sprint retrospectives are structured, time-boxed meetings dedicated to reflecting on the processes followed during past sprints aiming to identify strengths and weaknesses and discussing areas for improvement. Teams typically conduct these meetings at the end of a sprint, just before planning for the upcoming sprints. Learn more about sprint retrospectives in this article.

Table of Contents

1.

Introduction

2.

What is a Sprint Retrospective?

3.

Sprint Reviews vs. Sprint Retrospectives: Key Differences

4.

What Makes a Good Retrospective?

5.

Retrospective Techniques: Quick Overview w/ Examples

6.

Steps to Run a Sprint Retrospective for Your Team

7.

FAQs

Introduction

In this article, we’ve covered sprint retrospectives. You’ll learn what makes them crucial while working with agile projects, how they differ from sprint reviews, common techniques for running them, and practical steps to use them in your projects. 

What is a Sprint Retrospective?

Sprint retrospectives are structured, time-boxed meetings held at the end of each sprint. They come under the agile scrum framework aiming to help software teams reflect on the completed sprint and evaluate what worked well, what didn’t, and what needs to be improved in upcoming sprints.

Sprint Review vs. Sprint Retrospective: Key Differences

While sprint review and retrospective meetings might sound very similar in the way they’re typically run, there are a few nuances to consider. Here’s an overview table showing how they compare against each other:

 Sprint ReviewsSprint Retrospectives
ObjectivesTo showcase completed work, new features, and incremental progress to stakeholders for feedback.Discussions on the last sprint (or however far back). Identify what worked well, what didn’t, and what needs to be improved.
Focuses OnProductProcess
ParticipantsProduct Owners, Stakeholders, Developers, Scrum Team Scrum Team, Developers
FacilitatorProduct Owners, Scrum MasterScrum Master, Product Owner, or Development Team Member. Or, anyone who contributed to that sprint, even QA members, designers, or marketers.
Execution StageAfter sprint completion. After sprint review completion and before the next sprint planning meeting.
Average Duration1 hour per week iteration or about 2 hours for a 2-week sprint.30 minutes per week iteration or around 1 hour for a 2-week sprint.
Format Informal, typically using a few slideshows or quick presentations.Normally run using retrospective techniques. 
Follow-up ActivitiesRefine products, start working on the next features, and adjust scopes as per stakeholder feedback.Improve current processes and team dynamics, and address shortcomings.

What Makes a Good Retrospective?

Key principles for an effective retrospective:

Solution-Oriented and Practical Solutions

Retrospectives should be solution-oriented and focus on practical, to-the-point discussions. In every retrospective, teams should make decisions about what can be improved in the next sprint.

Environment of Trust Across Team Members

Since retrospectives involve discussing negative topics like what didn’t go well in the last sprint, it's important for everyone to feel safe sharing their thoughts. This means that what's discussed in the meetings won't be used against anyone, and no one’s words will be taken out of context. Moreover, disagreements shouldn’t ruin relationships among team members.

Sense of Ownership and Commitment Towards Improvement

A good retrospective should focus on the team’s participation. It should center around how team members work, how they can contribute, and how they can become more effective. Simply put, it should be about the team’s commitment to improving together.

Retrospective Techniques: Quick Overview w/ Examples

Here’s a quick overview of the nine retrospective techniques:

1 - Significant Events

Uses a simple horizontal line on the whiteboard or the virtual board to show the timeline of how far back the discussion is to be. Then, request team members to mark any significant events like:

  • Great outcomes 
  • Negative outcomes 
  • Unexpected events 
  • Changes in the team, or any other.

Example

An unexpected server outage in the 4th sprint’s 2nd week (in December 2024) significantly impacted the QA and testing efforts.

Also Read: Quality Assurance vs Quality Control

2 - Start, Stop, and Continue

For this, the facilitator talks to the task owners, requesting them to start working on things that’re required, stop doing what’s not required at that time, and continue working on processes that are working well. It’s an action-oriented technique.

Example

  • Start: More frequent code reviews. 
  • Stop: Holding long status meetings. 
  • Continue: Daily stand-ups

3 - The 4Ls: Liked, Loathed, Lacked, and Learned

Focuses on creating a shared understanding of what the team members liked during the past sprints, what they didn’t like, what was lacking, and what they learned during the iteration. 

Example

  • Liked: The team's collaboration. 
  • Loathed: Slow process of bug reporting and sessions. 
  • Lacked: Unclear communication on dynamic project requirements. 
  • Learned: New techniques for debugging using AI.

Report Bugs 10X Faster and Debug with AI

4 - Mad, Sad, and Glad

In this technique, team members show their emotional aspects or feelings about the iteration by sharing what made them mad, sad, and glad.

Example

  • Mad: Frequent disruptions in development and testing activities due to outages from the hosting provider. 
  • Sad: Missing the sprint goal. 
  • Glad: Quick support from co-workers and senior members.

5 - The Five Whys

This technique aims to get to the root cause of a specific problem by repeatedly asking "why".

Example

Problem: Late bug fixes. 

  • Why? Lack of testing. 
  • Why? Insufficient test data. 
  • Why? Delays in mocking and data creation. 
  • Why? Automation wasn’t used for generating data. 
  • Why? Limited resources allocated for automation.

6 - Sailboat

It’s a metaphorical visualization technique of the sprint as a “Sailboat” with: 

  • Wind: Positive factors that helped teams push forward.
  • Anchor: What held the members back, or any bottlenecks hit.
  • Rocks: Associated challenges, risks, and obstacles faced.
  • Land: Going forward, the goal for the next sprint.

Example

  • Wind: Improved tools, bug tracking, and bug reporting mechanisms. 
  • Anchor: Dependency on another team. 
  • Rocks: Frequent scope modifications.
  • Land: Delivering the new set of features as per the specs.

Also Read: Top 10 Bug Tracking Tools

7 - The What, So What, and Now What

Discussions on what happened during the iteration, why it matters, and what actions should be taken going forward.

Example

  • What: We missed the deadline for a key feature. 
  • So What: This impacts the overall project timeline. 
  • Now What: We need to re-prioritize tasks and allocate more resources.

8 - Based on the Input and Energy Levels Required 

This one aims to reflect on the input required for specific tasks and the energy levels experienced by the team members.

Example

Task A required a lot of input from multiple teams and drained significant energy due to constant coordination. The coordination should be more streamlined with smarter ways or better SOPs.

9 - Dot Voting

This technique requires team members to vote on the most important issues or action items to address during the next iteration to prioritize improvements.

Example

Each team member gets three dots to vote on the top three issues they want to discuss further. The issues with the most dots are addressed first.

Also ReadHow to Run Bug Bash Events?

Steps to Run a Sprint Retrospective for Your Team

Here are the steps for it:

Step 1 - The Prerequisites

Start by doing some prep work to make retrospectives as productive as possible. Make sure you have the following supplies:

For In-Person Meetings:

  • Meeting space
  • Whiteboard or a wall
  • Large paper sheets
  • Sticky notes
  • Markers
  • Pens
  • A timer

For Remote Meetings:

  • Video conferencing and screen-sharing tools, such as Zoom, Google Meet, or others
  • Virtual whiteboards
  • Messaging and collaboration tools, such as Slack and Microsoft Teams

Step 2 - Setting the Tone for Conversation 

Retrospectives can be challenging, so it's important to set the right culture of how it is conducted. As a facilitator, you should:

  • Listen to everyone with an open mind.
  • Focus on improving the environment, not on individuals.

Next, decide the timeline to be discussed. It's crucial to be clear on how far back you are going for retro-ing. Is it for the last two weeks, one month, or longer? 

Besides this, you can consider requesting everyone to leave their laptops and phones outside the door to set the tone for conversation.

Step 3 - What Went Well

Hand out sticky notes and pens to the participants and set a timer for 3-5 minutes. The facilitator should encourage participants to write as many ideas as they can, such as:

  • Team strengths.
  • Things that worked out well and as expected.
  • Great outcomes that exceeded expectations.

Writing one brief idea per sticky note works best and it’s better to elaborate on them later rather than doing everything in one go. 

Note that retrospectives are not just about focusing on what needs to be improved, but also about discussing how to make the good even better. 

Once the timer hits the 5-minute mark, request everyone to:

  • Post their ideas on the wall.
  • Share and elaborate them out loud.
  • Create a shared understanding for everyone to be on the same page. 

Going forward, the team can ask clarifying questions, but discussions should focus on empathy and understanding, not actions and implications. 

Encourage the team to group similar ideas. This allows you as a facilitator to identify common themes that need urgent attention. 

The complete step should take:

  • Around 5 minutes for writing and brainstorming.
  • 10-20 minutes for running through the themes that arise.

Step 4 - What Needs Improvement

Repeat the structure as the last step, but this time, focus on what didn’t go well. 

Quickly write down actions and outcomes that could have been better. When sharing, it's best to avoid criticizing others or jumping straight to solutions.

Step 5 - Closure and The Next Steps

Having identified what went well and what didn’t, determine suitable actions your team can take to improve those things. 

Allow each team member 3-4 votes (with the dot voting technique) for ideas that seem most pressing. Analyze the votes and spend a moment brainstorming on the most voted ideas the team should take action on. 

Once you have a list, agree on what actions you’ll take:

  • Assign owners
  • Set due dates

The whole process shouldn’t take more than 20-25 minutes. Next, quickly run through the follow-up items and the members who are responsible for completing them. 

Finally, thank everyone for their participation. 

FAQs

The goal is to evaluate the last sprint and find ways to improve. The scrum team discusses what went well, what didn't, and potential improvements, helping them adapt their processes based on feedback.

Written by

Nishil Patel | CEO & Founder

Follow

Nishil is a successful serial entrepreneur. He has more than a decade of experience in the software industry. He advocates for a culture of excellence in every software product.

Subscribe to our updates

Meet the Author: Nishil Patel, CEO, and Co-founder of BetterBugs. With a passion for innovation and a mission to improve software quality.

We never spam.

Nothing here!
Show us some love 💖. Try BetterBugs today if you haven’t already. A quick feedback and a rating on our Chrome web store page would be awesome!

Share your experience with the founderhere!

Don’t wait! Start reporting now.