Start-Stop-Continue examples for teams
Choose what to start, what to stop, and which useful practice to continue. Browse 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.
Use these examples well
- Make it specific
Use these as a starting point. Rewrite each card around what your team actually saw and why it mattered.
- Choose one next step
Pick one small change to try next. Give it an owner and agree when you’ll check whether it helped.
Frequently asked questions
What makes a good Start-Stop-Continue example?
It names an observable behavior within the team’s influence and is specific enough to test or protect. Strong examples include the context and the effect instead of using a label such as “communication.”
Why use Start-Stop-Continue in this order?
Start names the new experiment, Stop creates room for it, and Continue protects useful practices from being removed by accident.
How many actions should a team choose?
Brainstorm freely, then choose one or two changes and one Continue practice to protect. Give each change an owner, review point, and success signal.
Should Stop examples name individuals?
No. Describe the behavior, situation, and impact rather than blaming a person. The retrospective should improve the working system, not create a public performance review.
Can Start-Stop-Continue be used outside agile retrospectives?
Yes. The format also works for project reviews, meetings, onboarding, team agreements, and process changes whenever a group needs to protect, remove, and introduce practices.
Put the examples into practice
Adapt an example, collect the team’s evidence, vote, and leave with an owner and review date.