TL;DR: Most content on start stop continue treats it as a retrospective exercise — useful for a meeting, forgotten by Friday. This guide shows IT company owners how to run it as a structured process audit that produces concrete workflow changes, not a list of intentions. You'll leave with a repeatable system you can apply to any team or client delivery process.
What Is the Start Stop Continue Method?
The start stop continue method is a structured feedback framework that sorts team input into three categories: what to stop doing, what to start doing, and what to keep doing. It turns a broad question ("how do we work better?") into three specific, actionable buckets.
Most teams encounter it as a retrospective format, but that undersells it. As a process improvement framework, it functions more like a lightweight audit. Each category forces a decision: this activity costs more than it returns (stop), this gap is hurting us (start), this is working and worth protecting (continue).
The output isn't just a list of opinions. When your team flags a process to stop, that's a signal worth examining closely. Many of those flagged processes turn out to be strong automation candidates, not just things to drop. When they flag something to start, that's a workflow you need to build with enough structure to repeat.
The method works because it's fast, structured, and produces decisions rather than discussion. A session runs in 30 to 45 minutes and leaves the team with a prioritized list of changes, not a parking lot of ideas.
Why IT Teams Use This Framework for Process Improvement
IT teams run on cycles. Sprints end, deployments happen, incidents get resolved, and the same inefficiencies show up again two weeks later. That repetition is exactly where start stop continue for retrospectives earns its place.
The framework fits IT workflows because it maps directly onto what engineers and team leads already do: review what happened, decide what changes, move forward. It doesn't require a facilitator certification or a two-hour planning block. A focused 30-minute session at the end of a sprint produces actionable output.
Start stop continue agile adoption makes particular sense because sprint cadences create a natural forcing function. Every two weeks, you have a defined moment to ask whether your standups, your ticket workflow, your deployment checklist, or your on-call rotation is actually working. Without a structure like this, those conversations get deferred indefinitely.
The other reason IT teams reach for this method is that it separates observation from opinion. Engineers can flag that a manual QA step is slowing releases without it becoming a blame conversation. That matters in teams where process problems often get misread as performance problems.
For a broader look at how process fits alongside people and tooling decisions, how people, process, and technology shape operations gives useful context before you run your first session.
How to Run a Start Stop Continue Session Step by Step
Running a start stop continue session takes about 45 to 60 minutes and works best with 5 to 8 people: the team lead, 2 to 3 engineers, and whoever owns the process being reviewed. Larger groups dilute the signal.
Before the session, send a simple start stop continue template to participants 24 hours in advance. Ask each person to write 2 to 3 items per category independently, before the room fills with other people's opinions. Async pre-work is what separates a focused session from a complaint loop.
Run the session in this order:
Collect inputs silently first: Give everyone 5 minutes to add their items to a shared board (Miro, FigJam, or a plain spreadsheet all work). No discussion yet.
Group duplicates. Items that appear three or more times are your highest-signal findings. These are the changes worth acting on immediately.
Discuss "stop" items first: These tend to carry the most friction and the most emotion. Getting them out early clears the air for constructive conversation. Processes your team flags to stop are often the best automation candidates worth reviewing after the session.
Move to "start" and "continue:" For each "start" item, assign an owner and a deadline before the session ends. A "start" without an owner is just a wish.
Close with a prioritized shortlist: Limit action items to 3 to 5. More than that and nothing ships. Use a simple effort-versus-impact filter when prioritizing which changes to act on first.
After the session, document outputs and map "start" items to your sprint backlog directly. If a "start" item involves building a repeatable workflow, treat it as a process design task, not just a to-do.
The session only works if decisions leave the room with owners attached.
Start Stop Continue Examples in Project Management and IT
The framework lands differently when you see it applied to real IT work rather than generic team-building scenarios.
Start examples are the easiest to generate. In project management, that might mean starting weekly async status updates instead of a 45-minute sync, or beginning every sprint with a written risk log rather than a verbal mention in standup. For IT ops teams, common "start" items include automated alerting for SLA breaches, documented runbooks for recurring incidents, and post-mortems after any outage above a defined severity threshold.
Stop items are where the session earns its value. Most IT teams, when pushed, can name at least two or three meetings that exist out of habit. Common candidates: daily standups that have become status reports for management rather than coordination for engineers, manual ticket triaging that could be handled by routing rules, and approval chains with four sign-offs for changes that carry minimal risk. For a workflow examples for project management perspective, "stop" items often reveal where process debt has accumulated quietly.
Continue items matter more than most teams expect. Explicitly naming what's working protects those practices during periods of change or team turnover. In agile environments, this might be a blameless retrospective format, a definition-of-done checklist that actually gets used, or a pairing rotation that's improved code quality without being formally required.
For a start stop continue agile retrospective, the three categories map cleanly onto sprint cadences: stop items become backlog removals, start items become new process tickets, and continue items get documented as team norms.
This is also where the session becomes a process improvement framework rather than a venting exercise. When each example is concrete enough to assign an owner and a deadline, the output is actionable. When it stays abstract, nothing changes.
How to Turn Session Outputs Into Actual Process Changes
The session itself is the easy part. What kills most start stop continue efforts is the gap between "we agreed on this" and "someone actually changed it."
Start by assigning an owner to every output before the meeting ends. Not a team, a person. "We'll stop manual status update emails" means nothing until one engineer owns the cutover date. Give each item three fields: owner, deadline, and a success signal you can check in two weeks.
Then prioritize. Not everything from the session deserves equal urgency. A useful filter: sort items by effort versus impact. Changes that take under a day and remove recurring friction go first. For prioritizing which changes to act on first, a simple 2x2 grid (high impact / low effort in the top-left) works better than committee debate.
The "stop" column deserves special attention. Processes your team flags to stop are often the best automation candidates, not just things to delete. If your team said "stop manually copying tickets from email into Jira," that's not a deletion task, it's a trigger-based automation waiting to be built. Before you archive those items, run them through a quick check: is this something a rule or a script could handle? The answer shapes whether the fix takes 20 minutes or two weeks. The processes your team flags to stop are often the best automation candidates for exactly this reason.
For "start" items, building a repeatable workflow from what your team decides to start prevents the common failure where a good idea gets agreed on but never operationalized.
A filled-out start stop continue template with owners and deadlines attached is worth ten sessions that end with a slide deck and no next steps.
How Start Stop Continue Improves Team Productivity Over Time
The productivity gains from a start stop continue framework don't come from a single session. They come from running it on a consistent cadence, typically every four to six weeks, and treating each round as a data point in a longer series.
When you run multiple sessions, patterns emerge that a one-off meeting never surfaces. The same manual reporting task appears in the "stop" column three quarters in a row. That's not a preference, it's a signal. Those processes your team flags to stop are often the best automation candidates, and repeated flagging gives you the justification to act.
The "start" column compounds differently. Early sessions surface obvious gaps. Later sessions surface more precise ones, because the team has already cleared the noise. Over time, building a repeatable workflow from what your team decides to start becomes faster, because the inputs are more specific.
This is what separates start stop continue examples that produce real change from those that don't: regularity converts isolated feedback into a process improvement framework your team actually trusts.
Common Mistakes That Kill the Value of This Framework
The most common way start stop continue sessions fail is simple: the outputs never become decisions. Teams generate a solid list, then leave without owners, deadlines, or any mechanism to revisit what was agreed.
Four failure modes show up repeatedly:
No owner assigned:Every item stays collective responsibility, which means no one's responsibility.
Treated as a venting session: Complaints surface but nothing gets categorized as a decision or an action.
Run too infrequently: A quarterly session can't catch the patterns a monthly cadence reveals.
Results filed, not acted on: The doc lives in a shared folder. Nobody opens it again.
For start stop continue for retrospectives to produce real change, each item needs an owner and a next step before the meeting ends. Processes your team flags to stop are often the best automation candidates — but only if someone is accountable for prioritizing which changes to act on first.
Closing
The start stop continue method only delivers value when session outputs leave the room with owners and deadlines attached. Most teams run the session, feel productive for a day, then watch the list gather dust. The difference between a one-time retrospective and a repeatable process improvement system is what happens in the 48 hours after the meeting ends—when decisions become tracked tasks and automation replaces manual work.
Once your team has identified which processes to stop, start, or continue, the next question is execution: who owns the follow-through, and how do you prevent these changes from slipping into the backlog? That's where turning session outputs into tracked, assigned work becomes critical. Ready to see how WorksBuddy helps teams move from intention to implementation?
FAQ
How can I use the start stop continue method for process improvement?
Run it as a structured 45-minute audit with 5–8 people, collecting independent input first, then grouping findings by signal strength. Assign owners and deadlines to each output before the session ends—without owners, nothing ships.
What are some examples of start stop continue in project management?
Start: async status updates, risk logs, automated alerting. Stop: habit-driven meetings, manual triaging, over-approval chains. Continue: blameless retrospectives, definition-of-done checklists, practices that improve quality.
Can you explain the start stop continue framework for retrospectives?
It sorts team feedback into three actionable categories—stop doing, start doing, keep doing—turning broad "how do we work better" questions into concrete decisions with owners and deadlines, not just a list of opinions.
How does the start stop continue approach improve team productivity?
It separates observation from opinion, removes friction-causing processes, and protects what's working. By mapping outputs directly to sprint backlogs with assigned owners, teams move from intention to measurable workflow changes.
Get tactical playbooks every Tueday
One email. 5-min read. Tactical reads for B2B operators who actually run the business.
Join 48,000+ B2B operators · Unsubscribe anytime
Lauren Brooks is a Project Delivery Lead & Business Operations expert who has managed complex, multi-team projects across agencies, SaaS companies, and service firms. She writes about what separates projects that deliver on time from those that spiral; and how smart systems make the difference before problems even appear.