Good / Bad / Start / Stop retrospective
Good / Bad / Start / Stop does one thing the three column formats cannot: it separates noticing from deciding. Good and Bad collect what actually happened. Start and Stop collect what the team intends to do about it. Teams reach for this the moment they realise their Start column has quietly filled up with complaints.
No sign-up. You'll join as Visitor. Share the link and everyone's in.
The columns
Good
What happened that was worth it. Observations, not proposals: this column is a record of the sprint, not a plan.
Ask: What went well, whether or not we did it on purpose?
Good: the release went out on Tuesday with no rollback
Bad
What happened that hurt. The column that earns the format, because nothing here has to be anyone's suggestion yet.
Ask: What went badly, even if you don't know what to do about it?
Bad: we found out the schema had changed by breaking in production
Start
Decisions. Things the team will begin doing, drawn from what the first two columns turned up.
Ask: Given all that, what should we begin doing?
Start announcing schema changes in the channel before merging
Stop
The other half of the decision. Things the team will stop doing, for the same reasons.
Ask: Given all that, what should we stop?
Stop approving migrations without a named reviewer
What a filled-in board looks like
A four person team in the sprint after a schema change took the search service down for an afternoon, running an hour.
Good
Good: the release went out on Tuesday with no rollback
Good: two people picked up the incident without being asked
Good: the new smoke tests caught the second bad deploy
Bad
Bad: we found out the schema had changed by breaking in production
Bad: the runbook was six months out of date when we opened it
Bad: nobody could say who owned the search service during the incident
Start
Start announcing schema changes in the channel before merging
Start putting a named owner on every service in the catalogue
Stop
Stop approving migrations without a named reviewer
Stop treating the runbook as documentation rather than part of the change
What grouping surfaced
- All three Bad cards were one card: changes reaching production without the people downstream knowing, and nobody named to ask.
- The Good column was mostly the safety net working. Worth noticing, because it is the only reason the afternoon was not a day.
What they left with
- Rae adds a required platform reviewer on migrations, this week.
- Ola fills in the owner field for every service in the catalogue before the next retro, and the team reads the list out at it.
When to use it
- Teams whose Start column keeps filling with things that are really complaints
- Rooms where people want to say what happened before being asked to fix it
- Sprints with an obvious event in them: an incident, a launch, a deadline missed
- Mixed groups where not everyone has the standing to propose a process change
When not to: Skip it when the team is practised and time is short. The extra column and the grouping step between the halves cost about ten minutes, and a team that already writes decisions straight into Start gets nothing back for them. Use Start / Stop / Continue instead.
It has no single author. It is what Start / Stop / Continue turns into when a team keeps writing observations where actions should go, and it has been rediscovered independently by enough teams that most people meet it without ever being taught it.
Running it
- 01Set the stage. Say that the first two columns are for observations only.5 min
- 02Silent writing into Good and Bad, cards hidden. Nothing goes in Start or Stop yet.10 min
- 03Reveal Good and Bad, read out, and group the cards that are really one card.10 min
- 04Now open Start and Stop, and write against the themes on the board.10 min
- 05Vote on the Start and Stop cards rather than the observations.5 min
- 06Turn the top two or three into actions with owners.15 min
Facilitation notes
Hold the line on the first ten minutes. The whole value of the format is that nobody has to have a solution ready before they are allowed to say what happened.
Vote on the decisions, not the observations. Voting on Bad cards just ranks the team's misery and leaves you no closer to an action.
If Start and Stop fill up faster than Good and Bad, the team did not need this format. Run Start / Stop / Continue next time and save ten minutes.
A Bad card with no matching Start or Stop card is not a failure. Some things are worth recording and outside the team's reach, and pretending otherwise produces actions nobody does.
Variations
Good / Bad / Start / Stop / Continue
Adds back the column this format drops. Worth it for a team that has lost a good practice recently, because Continue is the only column that argues for keeping something. The cost is five columns, which is about as wide as a retro can get before people stop reading each other's cards.
The Good / Bad / Start / Stop / Continue template in full →Plus / Delta
The same split with two columns instead of four: Plus for what worked, Delta for what to change. It fits a fifteen minute retro at the end of a workshop or a day of interviews, where the full format would be heavier than the material.
Written asynchronously first
Open Good and Bad a day early and let people fill them in as the sprint ends, then run the live session on Start and Stop only. It suits distributed teams and gets better observations, because people write them while they are still annoyed rather than a week later.
Reach for a different format when
The team already writes decisions straight into Start and the extra ten minutes buys nothing.
Start / Stop / Continue retrospective →
The Bad column keeps filling with how the sprint felt rather than what happened in it.
Mad / Sad / Glad retrospective →
Common questions
›What is the Good Bad Start Stop retrospective?
A four column retrospective that splits the session in two. Good and Bad gather what happened during the sprint, then Start and Stop gather what the team will do differently. The first pair is observation, the second pair is decision, and keeping them apart is the point.
›Is Good Bad Start Stop the same as Start Stop Continue?
No. Start / Stop / Continue asks for decisions in all three columns and keeps a place for protecting what already works. Good / Bad / Start / Stop gives observations a home of their own but drops the Continue column, so nothing on the board argues for keeping a practice that is working.
›How long does a Good Bad Start Stop retro take?
About an hour for a two week sprint, which is ten minutes longer than the three column formats. The extra time goes on grouping Good and Bad before the team is allowed to write in Start and Stop.
›Should people write in all four columns at once?
No, and that is the one rule worth enforcing. Opening all four at the start collapses the format back into Start / Stop / Continue with a spare column, because people write the solution they arrived with instead of the thing they noticed.
›What if the Bad column is much longer than the Good one?
That is normal and not by itself a problem: bad things are more memorable and easier to name. It is worth worrying about when it happens every sprint, which usually means the team has no habit of noticing what works and will lose those practices without noticing either.
Other formats
Run a Good / Bad / Start / Stop retro now
Columns ready, link shareable, nothing to install.
Start a board →Need different columns? Build a custom board