Sprint Retrospectives: The Unsung Hero of Agile Success

I’ve either been a part of or have run Sprint Retrospectives for the last 15 years.

When done well, Sprint Retros make teams more effective, build trust and openness, and lead to overall better outcomes.

Sprint Retrospectives are easy to gloss over as just another meeting that happens when you do Agile, but they really need to be treated with a little more respect and not just another checkbox you need to check to say you do Scrum.

What Is a Sprint Retrospective?

A Sprint Retrospective is a meeting at the end of every sprint, usually two or three weeks.

The Retro is attended by all members of the Scrum Team (and no more, unlike the Sprint Review) and is a designated safe space where all team members can openly discuss how they think the previous sprint went.

The idea behind the Retro is to allow the team to learn from both mistakes and what went well and use that knowledge to be better and more effective in the future.

Let’s take an example:

In a Sprint Review, the team may mention that they were asked to work on stories that had not been properly specified or reviewed before the sprint started. This would then be a talking point and end up with an action item: “Do not work on any stories that are not fully specified and reviewed prior to the sprint starting,” which would become a working process for the team.

Why Do We Need a Structure for a Sprint Retrospective?

If the Sprint Retro is just to talk about what happened in the previous sprint, why bother with having a structure to the meeting? Why not just talk?

The outcome of every Sprint Retro should be between two and four actionable items that allow you to improve as a team.

Generally, you won’t get to the bottom of the most valuable points that must be taken away in an open forum.

With “Retro Games,” you are implementing a process that allows you as a team to hone in on what you need to change and what you need to continue doing.

Prerequisites for Effective Retrospectives

Before diving into methodology, there are a few fundamental requirements:

1. Team size: Scrum Teams should not exceed six people. Larger teams struggle to build trust and change quickly and should be split into smaller teams.
2. Psychological safety: Without a safe environment where people can speak openly, you’ll never get honest feedback and be able to make meaningful improvements.
3. Follow-through: If action items from retrospectives aren’t implemented, team members will quickly stop participating. Trust is built through action.

Now that we’ve covered the prerequisites, let’s examine the process.

What Is a Start, Stop, Continue Retrospective?

The Start, Stop, and Continue Retro “game” is a framework for quickly categorizing the team’s thoughts into three sections: start doing something, stop doing something, and continue doing something.

This straightforward approach asks team members three key questions:

1. What should we start doing?
2. What should we stop doing?
3. What should we continue doing?

This framework cuts through the noise and focuses directly on actionable changes.

The Process in Practice

Start Items

When collecting Start suggestions, we’re looking for new practices to adopt, such as:

Stop Items

The Stop list identifies waste and inefficiency:

• Committing code without running tests
• Allowing daily Scrums to exceed 15 minutes
• Skipping refinement when sprint deadlines are close.

Continue Items

The Continue section is about positive practices that need reinforcement before becoming habits:

• Reviewing others’ code before picking up new tasks
• Being constructive but accurate in code reviews
• Speaking daily to the Product team to ensure we’re on the right track

Keeping Retrospectives Fresh

To combat “Retrospective fatigue” (it’s genuine, I’ve seen it countless times), I use different facilitation techniques:

• Open floor discussions: Anyone can speak about anything they want.
• Round-robin contributions: Move from person to person and ask for at least one Start, Stop, Continue.
• Category-focused sessions: Just look at Stop items for one session.
• Mixed approaches: Combine all of the above.

This variation maintains engagement even after many sprints with the same team.

Decision-Making Process

When idea generation tapers off, we vote. I typically use multi-voting, giving each team member three votes to distribute however they choose. Multi-voting works well because many Retrospective actions are behavioral shifts rather than time investments. We typically select 2–3 focus areas to avoid overwhelming the team. We also regularly review the Continue list to graduate ingrained practices and remove irrelevant items.

The Compounding Effect of Continuous Improvement

One of the most potent aspects of regular Retrospectives is the compounding improvement over time. Compounding is often discussed in financial terms, but I feel that it doesn’t receive the respect it deserves in team improvement.

A 1% team improvement each sprint might seem tiny, but over a year of two-week sprints, the compounding effect transforms team performance. Teams that consistently implement small changes outperform those making occasional extensive overhauls.

Setting Up Subsequent Retrospectives

For each new Retrospective, I bring the previous session’s ideas on a large sheet that I tape to the wall as a reference. This provides continuity without dictating the new discussion.

Why This Approach Works in Real Teams

After running Sprint Reviews for many years, I’ve found this method consistently delivers results because:

1. It focuses on actions rather than feelings (though both have their place).
2. Every item leads directly to a behavioral change.
3. It respects the team’s time with its efficiency.
4. The continuous improvement compounds over time.

For teams focused on delivering results, particularly in time-sensitive environments like fintech, the Start, Stop, Continue framework provides the structure needed for meaningful improvement without excessive overhead.