Start-Stop-Continue

What it is

Start-Stop-Continue asks for three specific behaviors: something the team should start doing, something it should stop, and something worth continuing. Unlike Went Well / To Improve, every card here is phrased as an action instead of an observation — "stop merging without a second reviewer," not "code review is inconsistent." That framing works, since it's harder to write a vague Start-Stop-Continue card than a vague To-Improve card; the format forces a verb.

The three columns also map cleanly onto the three things a retro can actually change: a new habit, an old habit removed, and an existing habit reinforced. Went Well / To Improve mixes observation and action in the same two columns and relies on the facilitator to separate them during discussion; Start-Stop-Continue does that separation in the writing step instead, which front-loads the work but means less translation is needed once the board is full.

When to use it

Reach for this after a team already has a rough sense of its problems and needs to convert that sense into commitments. It also works well mid-project as a checkpoint format — "Continue" gives explicit credit to practices that are working, which "Went Well / To Improve" tends to under-recognize once a team gets used to them. It's a particularly good fit right after a process change — a new deploy pipeline, a new on-call rotation, a new code review policy — a few sprints in. "Start" and "Stop" cards naturally surface which parts of the new process are actually being followed versus quietly ignored, which a neutral "what went well" framing tends to miss because nobody thinks to write a card about a policy that's just being routinely skipped.

Common failure mode

"Continue" gets treated as filler and skipped, or filled with generic praise ("continue being a great team") that nobody can act on. That's a real loss: "Continue" is the column that stops a team from accidentally discarding a good practice while chasing new fixes. A retro that only ever produces Start and Stop cards will, over several sprints, erode process that was actually working, because nothing ever explicitly protects it.

The other common failure is treating "Stop" cards as a personal indictment rather than a process one — "stop skipping tests" reads very differently depending on whether it's aimed at a habit or a person. When you write and discuss Stop cards, frame them around the behavior, not the individual.

A third failure shows up specifically in teams new to the format: cards land in the wrong column because the line between "Start" and "Stop" isn't always obvious — is "stop reviewing PRs alone" a Stop card or is "start requiring a second reviewer" the Start version of the same idea? Don't spend meeting time debating column placement; the content is what matters, and a card in the "wrong" column still gets discussed and still becomes a commitment.

Example cards