How to Run a Sprint Retrospective Using the Start, Stop, Continue Method

I’ve been writing a lot of articles lately on Agile methodologies. And for this one, I wanted to cover how to get the most out of a Sprint Retrospective.

I’ve been participating and running Sprint Retrospectives now for 15 years and I truly believe that when done well, they are the best way to make a team more effective and more closely bonded.

What is a Sprint Retrospective?

A sprint retrospective is one of the key events in an Agile Sprint. The retrospective occurs at the end of each sprint and it is the meeting where the scrum team gets together to talk openly and honestly about the sprint that has just finished.

The purpose of the Sprint Retrospective is to find out things that went well in the previous sprint and things that didn’t.

Agile promotes iteration and improvement. The retrospective is a way to continuously improve the team and the team’s practices by regularly (at the end of each sprint) dissecting your working practices and trying to improve upon them.

Building the Foundation for Effective Retrospectives

Before diving into methodology, let's address three critical factors that determine how successful your sprint retrospective might be:

1. Team size matters: I've discovered that scrum teams larger than 6-7 people struggle with meaningful retrospectives. The dynamics change, people speak less freely, and you lose the intimate environment needed for honest feedback. If your team has grown too large, consider splitting it.

2. Trust is non-negotiable: I've seen brilliant retrospective frameworks fail in environments where team members don't feel safe sharing honest feedback. This foundation must be established first.

3. Actions speak louder than words: Teams quickly recognize empty exercises. If retrospective outcomes aren't implemented, people will lose faith and stop participating. Make sure you follow through.

The Mechanics of Start, Stop, Continue

The beauty of this approach is due to its simplicity.

Start, Stop, Continue is a framework that tries to get you and your team to categorize all of the aspects of work in the team (planning, execution, reviews, communication, and so on) into three simple categories:

• Things we should start doing (before starting a new code change, see if there are open pull requests to review),

• Things we should stop doing (submitting pull requests that are longer than X lines), and

• Things we should continue doing (keep the stand up to 15 minutes).

Here's how I structure these sessions:

Gathering "Start" Items

I ask: "What practices should we begin implementing that we currently don't do?"

Common themes I've seen across teams include:

• Earlier stakeholder demos

• More rigorous code review practices

• Better preparation before refinement meetings

• Cross-functional pairing opportunities

• More well-defined tasks

Finding the "Stop" Items

Next question: "What's currently slowing down our productivity or quality?"

Frequently mentioned items include:

• Context switching between multiple stories

• Late-sprint testing bottlenecks

• Inconsistent documentation practices

• Meeting overload

• Changing priorities mid sprint

Recognizing "Continue" Items

Finally: "What positive practices have we recently adopted that require reinforcement?"

This category functions as a temporary holding area. Once practices become second nature, they graduate from the list.

The Decision Framework

After generating ideas, decision-making becomes critical.

You now need to decide which items on the board (across all categories) you want to talk about.

There may be some retrospectives where you decide as a team that the most important items to talk about are all In the “start” category, there may be some meetings where you talk about items from the Start, Stop, and Continue categories. It really depends on what is deemed by the team to be the most important items that need addressing.

Here’s my preferred approach to picking the most important topics to discuss:

1. Group similar items for clarity. Are there three items on the board that are to do with different aspects of stability? Group them into one.

2. Allocate three votes per team member. Giving people limited options means that their votes truly matter. If you ask people to tag any items they see as important, you’ll more than likely get an overwhelming number of action items.

3. Select the top 2-3 items for action. It’s not possible to make too many changes in one go or in one sprint. Choosing 2-3 means that you are likely to be able to achieve them. Starting each retro by highlighting missed action items can be demoralizing. Limiting your action items hopefully mitigates this.

4. Assign clear ownership for each item. One person needs to lead each action item. Without clear ownership, the bystander effect is likely to happen.

The key insight: changing too many things simultaneously dilutes focus. A few well-implemented changes outperform numerous half-hearted attempts.

Avoiding Retrospective Monotony

Repetitive formats lead to diminishing returns.

There are various ways that you can “spice up” the Start, Stop, Continue framework to make sure that people don’t get bored and just go through the motions.

Some of the processes below augment the Start, Stop, Continue process changing it slightly to keep it interesting.

I've developed several variations to keep the process engaging:

• Silent brainstorming: Everyone writes ideas on sticky notes before sharing

• Theme-focused: Concentrate on specific areas (for example, "testing practices" or "collaboration"). Only do Start, Stop, and Continue on the chosen topic.

• Data-driven: Begin by examining sprint metrics, then discuss implications. Look at the sprint burndown, the velocity, the story breakdown and do Start, Stop Continue based on the data that you see. For instance, “Start breaking stories down to smaller chunks so that each story can be delivered quicker giving us a more smooth burndown”

• Rotating facilitation: Have different team members lead each retrospective. People engage more if they are actively leading a meeting. They will find ways to keep the others engages as well as they want to do a good job of running the meeting.

• Talking stick: Use a physical stick (yes, I’m serious) as a talking stick and only the person holding can talk. They are allowed to talk about whatever they want, good, bad, or indifferent. You can have one person taking the notes of what the person with the talking stick is saying. For instance, the person with the talking stick might say "I’d like to reduce the number of project meetings within the Sprint”. The meeting facilitator could then translate this to “Stop having so many project meetings in the sprint” and put it on the board.

The Mathematics of Team Improvement

Here's something rarely discussed in Agile circles but frequently mentioned in finance: the power of compounding. Just as compound interest transforms modest savings into significant wealth, small team improvements compound over time.

Consider this: A team implementing just one meaningful improvement per sprint will see huge results after a year. If each improvement increases efficiency by just 2%, the compounding effect after 26 two-week sprints is remarkable.

Teams that understand this principle outperform those making sporadic large changes.

Maintaining Continuity Between Retrospectives

I maintain a living document tracking all retrospective outcomes.

Before each new session, I review:

• Which items were successfully implemented

• Which items need continued attention

• Which items were dropped and why

This creates an improvement narrative that demonstrates the team's evolution.

Why This Framework Delivers in Real-World Scenarios

Having implemented this across multiple organizations, from startups to established enterprises, I've found the Start, Stop, Continue model succeeds because:

1. It creates immediate clarity on what requires action

2. It balances recognition of successes with acknowledgment of challenges

3. It creates a sustainable improvement cycle without overwhelming the team

4. It focuses on behavioral changes rather than vague aspirations

The best retrospectives I've facilitated didn't just improve processes—they transformed team cultures by establishing continuous improvement as a fundamental value.

For more content, follow me on my personal Blog, Just Another Tech Lead or on X.