Writing Effective Start Stop Continue Feedback

Write start stop continue feedback that works: specific, behavior-focused items with a situation and an effect, each one something a person could act on.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

The quality of a Start Stop Continue session depends on the items people write. A vague item such as "communicate better" gives the team nothing to act on. A specific item such as "start posting a short written summary after each customer call in the team channel" can be adopted the same day and checked at the next session. This skill covers how to write start stop continue feedback that is specific, behavior-focused and actionable, for a team retrospective or for feedback to one person.

The core technique is to write about behavior and its effect. The Center for Creative Leadership's Situation-Behavior-Impact model gives a simple structure: clarify the situation, describe the specific behavior you observed, and explain its impact. CCL's example contrasts a behavior description, "You interrupted me while I was telling the team about the monthly budget," with a judgment, "You were rude." The first can be discussed and changed. The second invites a defensive reply.

Structure helps. In higher education, Hoon and colleagues found that a structured Stop, Start, Continue form was associated with student feedback of greater depth than a free text box. Their example items were short and concrete, such as asking a lecturer to stop speaking so quickly or to start giving out class handouts. The three headings nudge writers to propose a change, and this skill builds on that by making each item precise.

You can tell an item is well written when someone who was not in the room would understand what it asks, when the person or team it concerns could start on it without asking for clarification, and when you could check at the next session whether it happened.

How It Works

Each column calls for a slightly different kind of sentence. A Start item proposes a new practice and should say what, when and ideally who. A Stop item names a current practice to drop and should describe the practice and its cost. A Continue item names a practice worth protecting and should say why it helps, so the team knows what to keep when things get busy. Retrium's column definitions make the same distinction: new things that would help, things that are not helping, and things that worked and should stay.

The SBI structure fits all three. For a Stop item: "In sprint planning (situation), we accept stories without acceptance criteria (behavior), which led to rework on two stories this sprint (impact)." For a Continue item: "In code review (situation), reviewers leave a summary comment first (behavior), which makes the review easy to act on (impact)." For a Start item, describe the situation and the behavior you want, then the effect you expect.

Keep items about practices and behaviors, and leave character out of them. "Stop being so negative in meetings" is a judgment. "Stop opening the design review with a list of objections before the designer has presented" is a behavior. In team retrospectives, most items should be about how the team works rather than about one person. Norm Kerth's Prime Directive frames a retrospective on the belief that everyone did the best job they could given what they knew at the time, which pushes items toward systems and away from blame.

Scope matters as much as wording. An item should be within the control of the people who will act on it. "Stop getting surprise requests from sales" is outside most engineering teams' control. "Start asking sales to route requests through the weekly intake meeting" is within it. When an item is outside the group's control, rewrite it as a request someone can make.

Finally, test each item before you post it. Read it as the person or team it concerns would. If it could be read as an attack, rewrite the behavior description. If it could mean two different things, add the situation. If nobody could act on it by the next session, make it smaller.

Step-by-Step Guide

Step 1: Collect raw observations

Before writing items, list what you noticed during the period under review: events, habits, frustrations, and things that went well. Do not sort or polish yet. Look at the sprint board, calendar and chat history if they help you remember. Aim for concrete moments rather than general impressions.

Step 2: Sort observations into Start, Stop and Continue

For each observation, decide whether it suggests adopting something new, dropping something current, or protecting something that works. If an observation fits two columns, it may be two items. If it fits none, it may be too abstract, so make it more specific or leave it for the free text box.

Step 3: Describe the behavior and its situation

Rewrite each item so it names a specific behavior in a specific situation. Replace adjectives like "slow" or "unclear" with what actually happens. Name the meeting, process or artifact involved. Keep people's names out of team retrospective items unless the item is praise.

Step 4: Add the effect

For each item, add a short clause saying why it matters: the time lost, the rework caused, the risk created, or the benefit gained. The effect is what persuades the team to act. It also helps the group prioritize later, because items with a clear cost are easier to compare.

Step 5: Check the tone

Read each item as its subject would. Remove words that judge character, such as "lazy," "careless" or "negative." Check that Stop items describe practices rather than people. Ask yourself whether you would be comfortable saying the item aloud to the person it concerns.

Step 6: Make it actionable and small

Check that each item describes something the group could do before the next session. Split large items into smaller ones. Rewrite items outside the group's control as requests. For Start items, suggest a first step if the change is big.

Step 7: Balance the columns

Look at your items across the three columns. If you have only Stop items, look again for practices that should continue, and name them specifically. If you have only Continue items, ask whether you are avoiding a difficult Stop. A balanced set gives the team a fair picture of the period.

Best Practices

• Use the SBI structure for every item. The CCL model of situation, behavior and impact keeps feedback specific and discussable.
• Write one idea per note. Combining ideas makes grouping harder and hides which part the group agrees with.
• Keep items within the group's control. Items the team cannot act on belong in a separate list of requests.
• Make Continue items as specific as Stop items. "Continue the good teamwork" is as vague as "stop the bad meetings" and gives the team nothing to protect.
• Leave out names in team retrospectives. Describe the practice, and raise individual feedback privately, for example in a 1-on-1.
• Write for the reader who was not there. If an item needs you in the room to explain it, add the situation.

Common Mistakes

• Writing judgments instead of behaviors: "Stop being disorganized" invites defense. Describe the behavior, such as "stop starting new tickets before the current one is reviewed."
• Writing items too big to act on: "Start improving our architecture" cannot be done by next sprint. Name a first step the team can take.
• Leaving out the effect: Without a reason, an item reads as preference. Add the cost or benefit in a short clause.
• Using the Stop column for personal criticism: Items aimed at a person damage trust and the format. Raise individual issues privately and keep team items about practices.
• Only writing Stop items: A board of complaints discourages the team and hides what is working. Look for specific practices to continue.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Start Stop Continue

Related Skills

• Writing Start Stop Continue Questions and Prompts
• Start Stop Continue in 1-on-1s and Performance Reviews
• Facilitating a Start Stop Continue Retrospective
• Categorizing and Prioritizing Start Stop Continue Items
• Building a Start Stop Continue Retrospective Template
• Running a Start Stop Continue Icebreaker

Sources

• Center for Creative Leadership: Situation-Behavior-Impact-Intent
• Hoon et al.: Stop, Start, Continue and constructive student feedback
• Retrium: Start Stop Continue retrospective technique
• Retrospective Wiki: The Prime Directive

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.