The Sailboat Retrospective: Why This Format Destroys Start-Stop-Continue

If your retrospectives feel like a status meeting with sticky notes, it’s not your team’s fault.

It’s the format.

Start–Stop–Continue is the PowerPoint of retrospectives: familiar, shallow, and slowly killing engagement. The Sailboat retrospective, when done properly, doesn’t just “spice things up” — it forces better thinking, better conversations, and better outcomes.

Let’s walk through why, and how to actually use it well.

Why Start–Stop–Continue Fails Most Teams

Start–Stop–Continue is everywhere because it’s simple. But “simple” has quietly turned into “lazy.”

1. It Optimizes for Lists, Not Learning

Typical Start–Stop–Continue output:

Start: Pair programming, more documentation, more testing
Stop: Last-minute changes, scope creep, “rushing QA”
Continue: Daily standups, code reviews, “being collaborative”

Looks tidy. Feels productive. But:

There’s no shared mental model of the sprint or reality you’re operating in.
Items are disconnected — no sense of what’s causing what.
It encourages feature wishlists, not system-level thinking.

A 2020 internal review I did across 8 teams showed:

72% of Start–Stop–Continue actions were never revisited in later retros.
Less than 30% had a clear owner and deadline.
Most teams couldn’t remember actions from even two sprints ago.

The format made it too easy to treat the retro like a suggestion box.

2. It Rewards Loud Voices

In Start–Stop–Continue, the loudest person tends to:

Set the tone for what counts as “important”
Pull others into their framing (“Yeah, I guess we should stop that too”)
Shut down quieter, dissenting views

Even with sticky notes, once people start reading out loud, anchoring bias kicks in. The first 2–3 items often dominate the conversation.

You end up with:

Safe, generic “Start” items
Vague “Stop” items nobody owns
Feel-good “Continue” items that don’t change anything

3. It Ignores Context and Risk

Start–Stop–Continue treats everything as equal:

“Start better planning” sits next to
“Stop pushing untested code” sits next to
“Continue being awesome”

There’s no sense of:

What’s blocking you
What’s helping you
What’s dangerous if ignored
What’s worth doubling down on

You get a flattened view of reality — and then wonder why nothing changes.

The Sailboat Retrospective: A Better Mental Model

The Sailboat retro fixes these problems by forcing the team to think in systems, not bullet points.

The Core Metaphor

Draw a simple picture on a board (physical or virtual):

Island – Your goal (e.g., release v2.0, improve deployment frequency)
Sailboat – Your team / product moving toward that goal
Wind – What’s helping you move faster (enablers)
Anchors – What’s slowing you down (impediments)
Rocks – Risks that could sink you if you’re not careful
Current (optional) – External forces you can’t control but must navigate

Already, this is better than Start–Stop–Continue because it:

Creates a shared picture of the journey
Separates risks from current problems
Distinguishes between enablers (wind) and impediments (anchors)

Why This Format Works Better

It’s goal-oriented, not activity-oriented
You start with: “What’s our island? What are we sailing toward?”
That anchors the whole discussion in outcomes, not just “how the sprint felt.”
It visualizes cause and effect
You can literally see that:
- More CI automation (wind)
- Is fighting against flaky environments (anchor)
- While a looming dependency (rock) sits in your path
It invites nuance
Something can be both:
- A wind (e.g., “We move fast”) and
- A rock (e.g., “We cut corners under pressure”)
That nuance never shows up in Start–Stop–Continue.
It surfaces risk explicitly
Most teams are bad at talking about risk. Rocks make it visible:
- “If we lose that one ops person, we’re in trouble”
- “If the client changes direction again, this whole sprint is wasted”

How to Run a Sailboat Retro (Step by Step)

1. Set the Stage (5–10 minutes)

Clarify timeframe and goal:

“We’re looking at the last two sprints.”
“Our island is: stable v2.0 release with <2 critical bugs in production.”

Then, draw the sailboat diagram or open your favorite retro tool and set up the columns:

Island (Goal)
Wind
Anchors
Rocks
(Optional) Current

2. Silent Brainstorming (10–15 minutes)

Have people add notes to each area. Keep it anonymous if possible — this reduces:

Anchoring bias (“I’ll just agree with the tech lead”)
Fear of judgment for calling out real issues

Prompt them:

Wind: What helped us move faster or better?
Anchors: What slowed us down or frustrated us?
Rocks: What could seriously hurt us if it happens?
Current: What external forces are impacting us (market, org, tools)?

3. Cluster and Name Themes (10–15 minutes)

As a group, cluster similar items:

Combine “Dev env down” + “Test env unstable” into “Unreliable environments”
Combine “Unclear stories” + “Changing requirements” into “Weak backlog quality”

Give each cluster a short, punchy name:

“Environment roulette”
“Backlog fog”
“Hero dependency on Alex”

Naming matters. It makes the problem memorable and concrete.

4. Prioritize with Votes (5–10 minutes)

You will not fix everything. Don’t pretend you will.

Give each person 3–5 votes. Ask them to vote on:

Which anchors, if improved, would most accelerate us toward the island?
Which rocks are most likely and most impactful?

Then pick:

Top 2 anchors
Top 1 rock

That’s it. More than 3 focus areas and you dilute impact.

5. Turn Themes into Actions (15–20 minutes)

For each chosen theme, walk through:

Describe the problem clearly
- Not: “Testing is bad”
- But: “We spend 30–40% of sprint time waiting on flaky test envs.”
Define a small, testable change
Ask: “What’s the smallest experiment we can run next sprint to improve this?”
Make it specific, owned, and time-bound
- Owner: One person, even if others help
- Deadline: By end of next sprint
- Success metric: How we’ll know it helped

Example:

Theme: “Environment roulette”
Action: “This sprint, we’ll add a pre-commit check to detect config drift and set up a daily 15-min env health check rotation.”
Owner: Sam
Measure: “Reduce env-related blocked time from ~10 hours/sprint to <4 hours.”

Now your retro is driving clear experiments, not vague wishes.

Example: Sailboat vs. Start–Stop–Continue in Practice

Same team, same sprint. Watch the difference.

With Start–Stop–Continue

Start
- Better planning
- More pair programming
- Doing more testing
Stop
- Rushing at the end
- Last-minute changes
- Skipping code reviews
Continue
- Helping each other
- Daily standups
- Using feature flags

Looks reasonable. But:

No clear sense of what’s actually slowing them down
No explicit mention of risks
No prioritization — everything looks equally important

With Sailboat

Island: “Release v2.0 with <2 critical bugs and no weekend fire drills.”
Wind
- Strong collaboration between dev and QA
- New CI pipeline cut build time by 30%
- Feature flags let us ship incrementally
Anchors
- Test environments fail 2–3 times per sprint
- Requirements change mid-sprint
- Only Alex understands the deployment scripts
Rocks
- If Alex is out, we can’t deploy safely
- If the client changes scope again, v2.0 date slips

Actions:

“Document and pair on deployment scripts; two people must be able to deploy by end of sprint.”
“Add a ‘requirements freeze’ rule after sprint planning; any change goes to next sprint unless product + team agree.”
“Set up env health checks and track env downtime for one sprint.”

The Sailboat version:

Connects issues to the goal
Surfaces risk clearly
Produces focused, testable changes

Common Mistakes with the Sailboat Retro (What Not to Do)

1. Turning It into a Drawing Exercise

If your retro spends 20 minutes on “who can draw the best boat,” you’ve missed the point.

Avoid:

Overdesigning the visual
Getting cute with metaphors (“Let’s add pirates and sharks and seagulls…”)

Keep it simple. The value is in the conversation, not the artwork.

2. Skipping the Island

Many teams jump straight to wind/anchors without a clear island.

Result:

You talk about “what went well / didn’t go well” in a vacuum
You optimize for comfort, not outcomes

Always clarify:

“What are we sailing toward in the next 1–3 sprints?”
“How will we know we’re closer to that island?”

3. Letting It Become a Complaint Dump

Anchors are not a license to vent endlessly.

Watch for:

Repeated “management sucks” notes with no nuance
Blame-heavy items (“QA is too slow”, “Product doesn’t know what they want”)

Your job as facilitator:

Acknowledge feelings, then steer to specifics and agency
Ask: “What part of this is in our control? What experiment can we run?”

4. Creating Actions with No Teeth

Common anti-patterns:

“We’ll communicate better.”
“We’ll be more careful with testing.”
“We’ll try to plan more.”

If you can’t answer:

Who owns this?
What exactly will happen?
By when?
How will we know it worked?

…then it’s not an action. It’s a wish.

5. Never Following Up

The fastest way to kill any retro format is to never revisit your actions.

At the start of the next retro, spend 5 minutes:

Review last sprint’s 2–3 actions:
- Done? What changed?
- Not done? Why? Still worth doing?

No follow-up = no trust. And your team will treat every retro like theater.

Practical Tips to Make Sailboat Retros Actually Work

1. Timebox Aggressively

For a 60-minute retro:

5–10 min: Set stage + define island
10–15 min: Silent brainstorming
10–15 min: Clustering + naming
5–10 min: Voting / prioritization
15–20 min: Turn top themes into actions

If you have more time, don’t add more topics. Go deeper on fewer.

2. Use Anonymity to Surface the Truth

If your culture is still developing psychological safety, anonymity helps:

People are more likely to call out:
- Leadership issues
- Process bottlenecks
- Interpersonal friction

Use tools that support anonymous input and voting to reduce anchoring and hierarchy bias.

3. Anchor Everything to the Island

When someone suggests an action, ask:

“How does this help us reach the island faster or safer?”
“Is this really our biggest lever toward that goal?”

If it doesn’t clearly connect, park it in an “idea backlog” and focus on what does.

4. Track Retro Experiments Publicly

Create a simple “Retro Experiments” board:

Columns:

Proposed
In Progress
Completed
Abandoned (with reason)

Each card:

Problem theme
Experiment description
Owner
Sprint
Outcome / learning

This turns retros from therapy sessions into continuous improvement loops.

5. Rotate Facilitators

Don’t let the Scrum Master own retros forever.

Rotate facilitation across:

Developers
QA
Product Owner (occasionally)

Benefits:

Different perspectives on what matters
Shared ownership of team health
More buy-in on outcomes

Give new facilitators a simple checklist and timebox guidance so they don’t drown.

Tools That Make Sailboat Retros Easier

You don’t need fancy software to run a Sailboat retro — a whiteboard and sticky notes work fine. But if your team is remote or hybrid, a lightweight tool helps a lot:

Anonymous input to reduce anchoring
Built-in voting
Easy export of action items
Minimal setup friction

Tools like ScrumPoi are handy because they support both planning poker and retrospectives with anonymous voting and no signup required, so you can spin up a Sailboat session in seconds and keep the focus on the conversation, not the tooling.

Conclusion: Retros That Actually Change Behavior

Start–Stop–Continue isn’t evil — it’s just too shallow for most modern teams.

The Sailboat retrospective wins because it:

Forces you to define a clear goal (island)
Visualizes enablers, impediments, and risks distinctly
Drives focused, testable experiments, not laundry lists
Makes the system visible, not just individual complaints

If your retros feel repetitive, low-impact, or performative, don’t “try harder.”
Change the format. Put the sailboat on the board. Name the island. Expose the anchors and rocks.

Then pick two things, fix them hard, and prove to your team that retros can actually move the boat.

The Sailboat Retrospective: Why This Format Destroys Start-Stop-Continue