Watch enough retrospectives and you notice a pattern. The team walks in with a list of complaints. They spend the hour fixing what is broken. They walk out feeling productive.
Then, a few sprints later, the thing that was actually working has quietly stopped happening. Nobody decided to kill it. It just faded, because nobody ever said out loud that it mattered.
That is the hidden cost of running a retro as a problem list. The fix is a format so simple it fits in three words.
A retro in three columns
Start Stop Continue is a retrospective format built on three questions. What should the team start doing? What should it stop doing? What should it continue doing?
It has been around since the 1970s as a plain feedback tool, and it spread through agile teams because it is fast and blameless. There is no jargon and no scoring. Anyone can run it in thirty minutes.
The three columns map to three kinds of change a team can make.
- Start is a new behavior worth adopting, like writing a one-page brief before every project kicks off.
- Stop is a habit to end, like the status meeting nobody reads the notes from.
- Continue is what already works and needs protecting, like the design review that keeps catching bugs before launch.
Two of those columns are about change. One is about preservation. That difference is where most teams go wrong.
How to actually run it
The format is simple, but a few mechanics make it far more useful.
Run it silently first. Give everyone a few quiet minutes to write their own notes before anyone speaks. This stops the loudest voice from anchoring the room and surfaces issues quieter people would never raise out loud.
Then group the similar notes together and look for themes. You will usually see the same three or four problems show up from different people.
Now dot-vote. Give each person a small number of votes and let them spend them on the items that matter most. You are not trying to fix everything. You are trying to find the two or three changes worth real effort this cycle.
Keep it timeboxed. A retro that runs long trains people to dread it, and a dreaded retro is one people stop preparing for.
It is the best default, not the only option
Start Stop Continue is not the only retro format. Mad Sad Glad sorts the team's feelings about the sprint. The Sailboat asks what pushes the team forward and what holds it back. The 4 Ls collect what people liked, learned, lacked, and longed for.
Those formats are useful for variety, and rotating them keeps retros from going stale. But Start Stop Continue earns its place as the default for one reason. It forces the Continue question by design.
The other formats let a team drift into pure problem-hunting. This one puts protection on the board every single time, which is exactly the habit most teams are missing.
The mistake: everyone skips Continue
Here is the pattern that shows up again and again. Teams crowd the Start and Stop columns and leave Continue almost empty.
It makes sense. Fixing problems feels like progress. Naming something that is already fine feels like a waste of a meeting.
But that empty Continue column is a slow leak. A good practice that nobody names is fragile. The person who quietly runs it leaves, or gets busy, or assumes someone else cares, and the habit disappears with no decision behind it.
The good practice nobody bothers to name is the one that quietly disappears.
There is a well-studied reason this stings. Loss aversion, from the work of Daniel Kahneman and Amos Tversky in 1979, shows that people feel a loss more sharply than an equal gain. Losing a practice that was working sets you back further than a new experiment moves you forward. Yet teams spend all their retro energy on the new and none on protecting the proven.
Why naming wins protects the team
Skipping Continue does something else, and it is worse than a lost habit. It slowly makes the retro feel unsafe.
If every retro is an hour of what went wrong, people learn that speaking up means getting a problem pinned to their name. So they say less. The retro gets quieter and more useless every sprint.
This is not a soft concern. Google ran a two-year study of 180 of its teams called Project Aristotle to find what makes teams effective. The single biggest factor was not talent or resources. It was psychological safety, a term coined by Harvard researcher Amy Edmondson, meaning a shared belief that the team is safe for taking interpersonal risks.
Teams higher in psychological safety spoke up more, used each other's ideas more, and were rated effective about twice as often.
The Continue column is where you build that safety on purpose. When people hear what they did well named out loud, the room stays open enough that they will also name the hard problems. Praise is not fluff here. It is what keeps the honesty flowing.
Turn talk into change
A retro can be perfectly run and still change nothing. The failure mode is a good discussion that produces no owners.
A retrospective without an owner and a due date is just scheduled venting.
So convert every item you voted up, in all three columns, into a concrete action. Each action gets one named owner and a due date. "We should document releases better" is a wish. "Priya adds a release checklist to the wiki by Friday" is a commitment.
Protect the Continue items the same way. If the design review is what keeps quality high, assign someone to defend it on the calendar so it does not get cut the first busy week.
Then close the loop. Start the next retro by reviewing last time's actions before anything else. Did they happen or not? Nothing kills a retro faster than watching the same problems return while the actions to fix them are quietly ignored.
One more thing sets the tone. Norm Kerth's Prime Directive, from his 2001 book on retrospectives, asks everyone to believe that each person did the best they could with what they knew at the time. Open with that. The goal is to fix the system, not to find someone to blame.
How to apply this on your next retro
You can put all of this to work in your very next session.
- Force the Continue column. Ask the team to name at least three things worth protecting before anyone touches Start or Stop.
- Write silently, then dot-vote. Surface honest input first, then narrow to the two or three changes worth real effort.
- Give every item an owner and a date. No owner and no date means it did not really make the list.
- Guard your wins. Assign someone to defend each Continue item so it survives the next crunch.
- Open the next retro with the old actions. Review what actually happened before you gather new feedback.
- Set a blameless tone up front. Fix the system, not the person.
The format is not the point. The discipline is. A team that names what works, protects it, and turns talk into owned actions gets steadily better. A team that only lists complaints just relives them.
Where this shows up in PM interviews
Retros are a favorite topic in product interviews, because they reveal whether you can lead a team, not just ship a feature. If you can explain why the Continue column matters and how you turn a retro into owned actions, you are showing exactly the judgment interviewers look for.
To practice that kind of answer out loud, allthingspm.app has 4,000+ mock PM interviews, interviews built from a real job description, and resume reviews against a JD.
Run the retro that protects your best habits, not just the one that lists your worst days.
References
- Start Stop Continue retrospective, format and origin (Retrium)
- Start Stop Continue guide (BetterUp)
- Understand team effectiveness, Project Aristotle (Google re:Work)
- Project Aristotle and psychological safety, summary (Psych Safety)
- The Retrospective Prime Directive, Norm Kerth (Retrospective Wiki)
- Prospect Theory and loss aversion, Kahneman and Tversky 1979 (overview)
