The Start, Stop, Continue retrospective

Every retrospective format is a way of asking the same question: what should we do differently? Start, Stop, Continue asks it in three parts. It has no trademark and no author to credit. It is a prompt that teams have used for decades, and its main virtue is that anyone can run it with a whiteboard in under an hour.

What neither source prescribes

The Guide says what a Sprint Retrospective is for and leaves the method to the team. Its purpose is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and the Definition of Done, identifies assumptions that led it astray, and discusses what went well, what problems it met and how they were or were not solved. It identifies the most helpful changes and addresses the most impactful ones as soon as possible, possibly adding them to the next Sprint Backlog.

Nothing there names a format. Start, Stop, Continue is one of many ways to meet the description. A vendor guide to retrospectives lists it as one of several prompts a team can use, alongside More and Less, and Glad, Sad and Mad, and advises varying the format while keeping timing, attendees and the general shape consistent.

The three columns

Start. Things the team does not do now and thinks it should: a practice, a conversation, a measure. Examples: "pair on the first day of each risky item", "invite support to the Review".

Stop. Things the team does that are not helping: a meeting, a report, a habit. Examples: "stop starting new items before reviews are cleared", "stop sending the weekly status spreadsheet".

Continue. Things that are working and need protection. Examples: "keep the Friday demo with the designer", "keep the five-minute parking lot after the Daily Scrum".

The third column is easy to skip and should not be. A team that only fixes problems can change the things that work without noticing. Naming them is how a team protects its good habits.

How to run it

A one-hour version for a two-week Sprint:

1. Set the scene (5 minutes). State the purpose and the ground rule that everyone speaks for the team, not against a person. Recall the Sprint Goal and what happened.
2. Write silently (8 minutes). Each person writes cards for each column, one idea per card. Silent writing stops the loudest person from setting the agenda.
3. Share and group (12 minutes). Put the cards up, read them out and group similar ones. Do not debate yet.
4. Vote (5 minutes). Each person gets a small number of votes, often three, to mark what matters most.
5. Discuss the top items (20 minutes). For each, ask what is behind it and what a small change would look like. Decide on an action, an owner and a check date.
6. Close (5 minutes). Read back the actions. Ask what the team would change about the retrospective itself.

The Guide expects the most impactful improvements to be addressed as soon as possible, so put actions on the Sprint Backlog. See retrospective actions that actually happen.

A worked example

This is an illustrative board for a team of six after a messy Sprint.

In the grouping step, two Stop cards and one Start card turn out to be about the same issue: reviews wait too long. The team votes, and that cluster gets the most votes. In the discussion, they find that only two people feel confident to review the payment code. The action: pair a third person on the next payment change, and agree that no one starts a new item while a review is waiting longer than a day. The owner is the developer who raised it, and they will check the board at the next Daily Scrum on Thursday.

One action, one owner, one check date. The retrospective ends on time.

Going deeper than the first answers

The format can lead to shallow lists such as "communicate more". A few moves help.

Ask for an example. "When did we last see that?" turns a vague idea into something specific.

Ask why twice or three times. Not as an interrogation, but to move from a symptom to a cause.

Look for patterns across Sprints. If "stop interrupting developers" appears for the fourth time, the issue is structural. Take it to the Scrum Master for organisational action.

Turn Stop items into experiments. "Stop doing X" is often easier to agree as "pause X for one Sprint and see". This lowers the stakes.

Check the Continue column for risks. A thing that works may depend on one person.

A short note on facilitation

Whoever runs the session should resist the urge to answer their own questions. The facilitator's job is to keep the time, make sure quiet people have a chance to speak and keep the discussion on the chosen items. The Guide gives the Scrum Master the responsibility of ensuring that the event takes place and is positive and productive, and does not say the Scrum Master must always lead it. Rotating the facilitator, so that each team member runs the session in turn, is a good way to spread ownership and often improves the quality of the conversation, because the person leading has to think about how it will go.

When to change format

Use Start, Stop, Continue when the team is new, the Sprint was uneventful, or time is short. Move to a richer format when:

• the same items keep returning;
• the team needs to explore a particular event or feeling, in which case a timeline or a feelings-based prompt may work better;
• the conversation lacks energy, which a change of prompt may restore.

The format you choose matters less than the follow-through. A team with a plain format and finished actions will improve faster than one with an inventive format and forgotten ones. See when retrospectives go stale.

Common mistakes

• Turning Stop into a complaint list. Every Stop item needs an action, even a small one.
• Skipping Continue. You then never know what to protect.
• Too many actions. Three is plenty. The Guide asks for the most helpful changes.
• The Scrum Master doing all the talking. The team owns the retrospective.
• Using the same format forever. It is simple, and simplicity can turn into habit.

How to practise it

Run it once with only three actions allowed and a named owner for each. In the simulator the retrospective at step 4.2 uses a Start, Stop, Continue board and asks you to choose actions, which is a safe place to try the format.