Start, Stop, Continue retrospective examples for product teams

A Start, Stop, Continue retrospective organises feedback around working practices. Start asks what the team could introduce. Stop asks what creates unnecessary effort or confusion. Continue asks what already helps and should be preserved.

Use a defined period such as the last release or fortnight. Ask participants to describe an event before proposing a change. “Start writing decisions down” is more useful when it includes the example that made someone lose track of a decision.

These are fictional examples, not a recommended policy for every team. Choose the row closest to your situation and replace it with what you actually observed. The same practice can help one team and burden another.

First, explain the scope and allow quiet writing. People can add notes to any column; they do not need an equal number in each. If you use Retro, a facilitator can rename the three section headings in board settings to Start, Stop and Continue.

Second, read and clarify the notes. Group related suggestions, but check with the authors before treating two notes as the same problem. “Stop surprise requests” and “Start a support rota” may connect, yet they may also describe different experiences.

Third, agree which theme needs discussion. Votes can guide the choice, with a separate check for urgent concerns. Finally, select a change that fits the team’s capacity and record how you will review it.

It is common to write “Stop poor communication” alongside “Start better communication”. The pair repeats a goal without helping anyone act. Ask what information was missing, who needed it and at what point in the work.

A more useful pair might be “Stop relying on a meeting recording for release details” and “Start posting a three-bullet release note”. Even then, consider whether one experiment can test the idea before committing to a permanent process.

Give Continue its own discussion. Ask what makes the practice useful and what could threaten it. “Continue pairing” might become an agreement to protect a short pairing slot during the next busy release week.

The columns are prompts for the conversation, not a requirement to leave with an action from each one. One experiment may be enough. Write the behaviour, an owner, a trial period and a review question.

For the release-note example, agree who drafts the first note, which release will use it and whether support had the context it needed afterward. Reopen that action at the next retrospective before adding more changes. Keep the original notes so you can connect the experiment back to the team’s experience.