Start-Stop-Continue examples for teams
Decide what the team should start, what needs to stop, and which useful practice deserves protection. Find specific examples for delivery, planning, meetings, collaboration, product discovery, and remote work.
Software delivery examples
Start
2- reviewing one escaped defect each week and recording the prevention change.
- naming the rollback signal before a high-risk release begins.
Stop
2- committing sprint work before external dependencies have an owner and due date.
- treating a green happy-path test as proof that failure states are covered.
Continue
2- splitting risky changes into pull requests that can be reviewed within one workday.
- using feature flags for changes that need a controlled rollout.
Sprint planning and priority examples
Start
2- identifying external dependencies during refinement and naming an owner for each.
- checking planned work against actual capacity before the sprint is finalized.
Stop
2- pulling stories into a sprint before acceptance risks are clarified.
- using yesterday's velocity as a commitment when team availability changed.
Continue
2- using a written sprint goal to decline unrelated work.
- breaking uncertain work into a short discovery step before estimating delivery.
Meeting and decision examples
Start
2- closing every meeting by reading back decisions, owners, and review dates.
- canceling a recurring meeting when the agenda is empty one day beforehand.
Stop
2- holding recurring meetings that end without a decision or next action.
- reopening settled decisions without naming what new evidence changed.
Continue
2- recording decisions beside the work they affect.
- sharing context before meetings that require a decision.
Collaboration and handoff examples
Start
2- inviting Support into refinement when a change alters a customer workflow.
- documenting the operational owner before a new service launches.
Stop
2- handing completed stories to QA only at the end of the sprint.
- assigning cross-team questions without a named responder and expected date.
Continue
2- pairing when work crosses an unfamiliar service boundary.
- asking the receiving teammate to confirm the handoff context they need.
Product discovery examples
Start
2- attaching a target user and measurable outcome to each experiment.
- sharing contradictory customer evidence alongside the dominant pattern.
Stop
2- treating the loudest request as evidence of a broad customer problem.
- running experiments without deciding when the result will be reviewed.
Continue
2- testing low-fidelity concepts before committing engineering time.
- writing down which customer signal would change the product decision.
Remote and hybrid teamwork examples
Start
2- giving everyone two minutes of silent writing before live discussion.
- rotating meeting times when the same time zone repeatedly carries the inconvenience.
Stop
2- making hallway decisions without an asynchronous summary.
- assuming cameras are required for someone to be engaged.
Continue
2- documenting decisions for teammates outside the meeting time zone.
- using asynchronous updates for status that does not need discussion.
Turn an example into a strong card
- Ground the card in what happened
Use examples as a starting point. Rewrite each card around what your team saw and why it mattered.
- Leave with one next step
Pick one small change to try next. Give it an owner and agree when you will check the result.
Frequently asked questions
What makes a good Start-Stop-Continue example?
It names an observable behavior within the team's influence and gives enough detail to test or protect it. A strong example includes the context and effect. A broad label such as communication leaves too much open to interpretation.
Why use Start-Stop-Continue in this order?
Start names the new experiment. Stop creates room for the change, and Continue protects useful practices from accidental removal.
How many actions should a team choose?
Brainstorm freely, then choose one or two changes. Protect one Continue practice as well, and give each change an owner, a review point, and a success signal.
Should Stop examples name individuals?
No. Describe the behavior, situation, and impact, then keep the person's name out of the card. The retrospective should improve the working system. Public performance review belongs elsewhere.
Can Start-Stop-Continue be used outside agile retrospectives?
Yes. The format also fits project reviews, meetings, onboarding, team agreements, and process changes whenever a group needs to protect, remove, and introduce practices.
Bring one example to the board
Adapt one example to your team, collect the evidence, and ask everyone to vote before you choose the next step as a group. Before the retrospective ends, name the owner and set a review date.