Sailboat Retrospective: How to Run It, Questions to Ask, and a Worked Example (2026)
Short answer
A sailboat retrospective is a visual team retrospective that pictures your team as a boat sailing toward a goal. The team places notes in five areas: the island (goal), the wind (what pushes you forward), the anchors (what slows you down), the rocks (risks ahead) and the sun (what keeps morale up). It takes 45–90 minutes and should end with two or three owned action items.
The format works because a picture is easier to talk about than a list. People who would not say "our approval process is a bottleneck" in a meeting will happily stick it on the anchor. It also looks ahead: unlike "what went well, what didn't," the rocks make the team name risks before they hit.
Key takeaways
Five areas, not four. Many guides leave out the sun; it keeps the session from turning into a list of complaints.
Anchors are now, rocks are next. Anchors slow you down today; rocks are risks you can still steer around.
Timebox it. A 60-minute session splits into roughly 10 minutes of setup, 15 of silent writing, 20 of discussion and 15 for voting and actions.
It works for incident reviews too. On-call and SRE teams can use the same board to review a major incident or a quarter of on-call.
The five areas of a sailboat retrospective
Each part of the picture asks the team one question. Draw it on a whiteboard or open it in any retrospective tool, then let people place their notes where they belong.
Area | Question | What belongs here | Example note |
|---|---|---|---|
Island | What is our goal? | The outcome the team is working toward, short or long term | "Ship the new billing flow by end of Q4" |
Wind | What pushed us forward? | Practices, tools and people that helped | "Pairing on the API cut review time in half" |
Anchor | What slowed us down? | Problems that are hurting the team right now | "PRs wait two days for a reviewer" |
Rocks | What risks lie ahead? | Things that have not hit yet but could | "Our only database expert leaves next month" |
Sun | What kept morale up? | Wins, kudos and moments worth repeating | "The customer demo went better than planned" |
The anchor and the rocks are the two areas teams mix up most. A simple test: if it already cost you time, it is an anchor; if it might cost you time later, it is a rock. Some teams draw a shark or an iceberg instead of rocks; the meaning is the same.
Why the sailboat format works
The sailboat is more than a fun picture. Three well-documented effects explain why it surfaces more, and more honest, input than an open discussion.
1. It moves the conversation from people to the boat. Notes describe forces acting on the team, not individuals. That matters, because Google's Project Aristotle, a study of 180 of its own teams, found psychological safety (feeling safe to take interpersonal risks) was the most important of the five dynamics that set effective teams apart. The idea comes from Amy Edmondson's 1999 research on 51 teams, which linked psychological safety to learning behavior and performance.
2. Silent writing produces more ideas than talking. In their 1987 study of brainstorming, Michael Diehl and Wolfgang Stroebe found that production blocking (people waiting for their turn to speak, and losing ideas while they listen) accounted for most of the productivity loss in group brainstorming. Individuals writing on their own before any discussion consistently generated more ideas. The sailboat's silent-writing step applies exactly that finding.
3. It looks forward as well as back. The 2020 Scrum Guide defines the purpose of a retrospective as planning ways to increase quality and effectiveness. Most formats only review the past; the rocks make the team name risks while they can still be avoided, and the island checks that everyone is heading for the same goal.
When to use a sailboat retrospective (and when not to)
The sailboat works best when the team needs to look both back and ahead. It is less useful when the problem is narrow or the team needs a different conversation.
Use it when | Choose another format when |
|---|---|
A project or quarter ends and you want to plan the next stretch | You need a deep technical root cause for one failure; use a blameless postmortem instead |
The team has drifted from its goal or disagrees on what it is | The team is in conflict; start with a format focused on feelings, such as Mad, Sad, Glad |
Your usual "what went well / what didn't" format has gone stale | The sprint was routine and a 15-minute check-in is enough |
Risks are piling up and nobody is naming them | You have fewer than 30 minutes; the sailboat needs time to discuss risks properly |
A new team or new members need an easy, visual starting point | You ran a sailboat in the last two or three retros; rotate to keep it fresh |
The format came from the "Speed Boat" exercise, one of the collaborative workshop techniques Luke Hohmann described for product teams in his book Innovation Games (2006), which focused on anchors only. Agile teams later added the wind, rocks, island and sun to turn it into a full retrospective.
How to run a sailboat retrospective in 60 minutes
This agenda fits a team of 5–9 people. For larger groups, add 10–15 minutes to the discussion or split into two boats and merge the results.
Before the session (10 minutes of prep)
Draw the board or open a sailboat template in your retro tool.
Write the island first: the goal the team was working toward. If the goal is unclear, that is the first topic of the retro.
Bring last retro's action items, so you can check what actually happened.
The 60-minute agenda
Step | Time | What happens |
|---|---|---|
1. Set the stage | 5 min | Explain the five areas and the ground rule: discuss systems and decisions, not people. Review last retro's actions. |
2. Confirm the island | 5 min | Agree on the goal. Everything else is measured against it. |
3. Silent writing | 10–15 min | Everyone writes notes alone and places them on the board. Writing silently keeps the loudest voice from setting the agenda. |
4. Read and group | 5 min | Read notes aloud by area; cluster duplicates. |
5. Discuss | 15–20 min | Go through wind and sun briefly, then spend most of the time on anchors and rocks. |
6. Vote | 3 min | Each person gets three dots for the anchors and rocks that matter most. |
7. Decide actions | 10 min | Turn the top two or three items into actions, each with one owner and a due date. |
8. Close | 2 min | One word from each person on how the session felt. |
Why this order works. The agenda follows the five phases that Esther Derby and Diana Larsen set out in Agile Retrospectives (2006), the most widely used structure for retrospectives: set the stage (steps 1–2), gather data (steps 3–4), generate insights (step 5), decide what to do (steps 6–7) and close (step 8).
The ground rule to read aloud. Many facilitators open step 1 with Norm Kerth's Retrospective Prime Directive from Project Retrospectives (2001). In short: whatever we discover, we assume everyone did the best job they could, given what they knew at the time, their skills, the resources available and the situation. It sets a blameless tone in one sentence.
How long is right? The Scrum Guide caps a retrospective at three hours for a one-month sprint and expects shorter sessions for shorter sprints. For a two-week sprint, 60 minutes is enough for a sailboat; allow 90 for a quarter or a project.
After the session
Put the actions where the team already works (your sprint board or ticket queue), not in a slide deck. Start the next retrospective by checking them. An action nobody checks is the most common reason retrospectives stop changing anything.
Sailboat retrospective questions for each area
A single question per area is enough to start. When notes dry up, use these prompts to dig deeper.
Island (goal)
What were we trying to achieve this sprint, quarter or project?
Would everyone on the team describe the goal the same way?
Did the goal change along the way? Who changed it, and did we notice?
Wind (what pushed us forward)
What made the work faster or easier than expected?
Which tool, practice or habit would we hate to lose?
Who helped us, inside or outside the team?
Anchor (what slowed us down)
Where did work wait: for reviews, approvals, environments or answers?
What did we do manually that a tool could do?
What did we keep repeating because of a problem we never fixed?
Rocks (risks ahead)
What could stop us from reaching the island next time?
Which part of the system or process depends on a single person?
What are we assuming will be fine without checking?
Sun (what kept morale up)
What are we proud of from this period?
Who deserves a thank-you that they have not heard yet?
What moment would we like to repeat?
Running it remotely or asynchronously
The sailboat translates well to distributed teams, because the board is the meeting. Three adjustments make the difference.
Remote, live. Use an online whiteboard or a retro tool with a sailboat template, and hide notes until silent writing ends so people are not anchored by early posts. Ask everyone to turn on video for the discussion and voting steps only. For more than eight people, use breakout rooms of four during writing and grouping.
Async across time zones. Open the board for 48 hours and ask everyone to add notes in their own working hours. Then hold a 30-minute live call just for discussion, voting and actions. The writing step is the part that benefits most from async; the decision step still works best live.
Hybrid. Give people in the room a laptop each, rather than a physical whiteboard, so remote participants see every note at the same time as everyone else.
Using a sailboat retrospective for incident reviews and on-call
Most guides stop at sprints. The same board works well for operations teams, in two situations: reviewing a major incident with the whole team, and looking back on a quarter of on-call. It does not replace the written postmortem; it turns that document into a conversation the team actually takes part in.
Area | In an incident review | In an on-call retrospective |
|---|---|---|
Island | The service goal: an SLO, or "restore checkout within 30 minutes" | Sustainable on-call: few night pages, fair load, fast response |
Wind | What sped up the response: a clear runbook, a fast first alert, a decisive incident lead | Practices that made shifts easier: good handoffs, tuned alerts, reliable escalation |
Anchor | What slowed it down: noisy alerts, a missing runbook, unclear ownership, a slow escalation | What made shifts harder: duplicate pages, alerts with no action, unclear service ownership |
Rocks | Latent risks the incident exposed: single points of failure, untested failover, expiring certificates | Risks to the rotation: too few people, one person holding all the knowledge, upcoming leave |
Sun | Good teamwork under pressure: who stepped in and what went well | Shifts that went well, and colleagues who covered for others |
Bring data, not memories. People remember the stressful parts of an incident, not the sequence. Open the session with the incident timeline and a few numbers: time to detect, time to acknowledge and time to resolve (MTTD, MTTA and MTTR), and how many alerts fired. For an on-call retrospective, bring pages per person and night pages per person; uneven numbers are an early warning sign of on-call burnout.
Keep it blameless. Notes describe systems and decisions, never individuals. "The alert went to a channel nobody watches" is an anchor; "Ali missed the alert" is not. This is the same standard Google's SRE book sets for postmortems: identify the contributing causes without indicting any individual or team.
How ITOC360 helps. ITOC360 keeps the full incident timeline, alerts, chat and actions in one place, and drafts an AI retrospective when the incident closes. Bring that draft to the sailboat session as the starting point. Many anchors in incident reviews are alert noise; AI alert correlation groups duplicate alerts into one incident before anyone is paged, so the next review has fewer of them.
Worked example: a filled-in sailboat board
Here is what a finished board looks like. The team is a six-person payments team reviewing its third quarter, which included one major checkout outage. The example is illustrative; numbers in brackets are dot votes.
The island: Keep checkout availability at 99.9% and ship one-click refunds by the end of the quarter.
Area | Notes on the board |
|---|---|
Wind | Feature flags let us roll back refunds in minutes (4) · Pairing on the payment API cut review time · The new runbook for card-provider failures was used during the outage |
Anchor | The outage alert fired 40 times in 10 minutes, so the first real signal got lost (6) · PRs waited two days for a reviewer (3) · Staging data is too old to reproduce bugs (2) |
Rocks | Only one person knows the reconciliation job (5) · Our TLS certificate for the payment gateway expires in seven weeks (2) · Black Friday traffic is three times normal |
Sun | Customers praised one-click refunds in support tickets · Two people covered on-call for a colleague on leave without being asked |
Actions agreed (top three by votes):
Action | Owner | Due | From |
|---|---|---|---|
Group duplicate outage alerts into one incident and page once | Platform lead | Two weeks | Anchor (6) |
Pair a second engineer on the reconciliation job and write its runbook | Payments lead | End of next sprint | Rocks (5) |
Add a 30-day expiry alert for every payment certificate | On-call engineer | One week | Rocks (2) |
Notice what the board did that a plain "what went well" list would not: the certificate expiry and the single-person dependency only came up because the rocks asked about risks that had not hit yet.
Common mistakes and how to avoid them
Skipping the island. Without an agreed goal, wind and anchors have nothing to be measured against. Confirm it in the first five minutes.
Spending all the time on the wind. Positive notes are easy to discuss. Cap wind and sun at five minutes so anchors and rocks get the time.
Mixing anchors and rocks. Use the test: already cost us time is an anchor; might cost us time is a rock.
Too many actions. Five actions usually means none get done. Pick two or three, each with one owner.
No follow-up. Open every retrospective by checking the last one's actions.
Blaming people. A note that names a person turns the session defensive. Rewrite it as a system or process problem.
Variations: speedboat, pirate ship and more
Variation | What changes | Use it when |
|---|---|---|
Speed Boat (Luke Hohmann) | Only the boat and anchors | You want to focus purely on what slows the team down |
Sailboat with sun | Adds the sun for morale | Default for most teams |
Iceberg or shark | Replaces the rocks | You want hidden or sudden risks to feel more urgent |
Waves | Adds choppy water for anxieties | The team is under stress and needs to name worries |
Pirate ship | Adds pirates for external threats such as competitors or vendors | Risks come mostly from outside the team |
Hot-air balloon | Hot air (lift), sandbags (weight), storms (risks), sun | You have used the sailboat recently and want the same structure in a new picture |
Frequently asked questions
What is a sailboat retrospective?
A sailboat retrospective is a visual agile retrospective in which the team pictures itself as a boat heading for an island. Notes go into five areas: the island (goal), wind (what helps), anchors (what slows the team down), rocks (risks ahead) and sun (what keeps morale up).
How long does a sailboat retrospective take?
Plan 60 minutes for a team of 5–9 people: about 10 minutes of setup, 15 of silent writing, 20 of discussion and 15 for voting and actions. Small teams can finish in 45 minutes; large or distributed teams may need 90.
What is the difference between anchors and rocks?
Anchors are problems already slowing the team, such as slow code reviews. Rocks are risks that have not hit yet but could, such as a key person leaving or a certificate about to expire.
Is a sailboat retrospective the same as a speedboat retrospective?
Not quite. The speedboat, a product-workshop exercise from Luke Hohmann's book Innovation Games, focuses only on the anchors. The sailboat adds the wind, rocks, island and sun, so the team also discusses what helps and what lies ahead.
What are good sailboat retrospective questions?
Ask one question per area: What is our goal? What pushed us forward? What slowed us down? What risks lie ahead? What kept morale up? Follow-up prompts for each area are listed in the questions section above.
Can you use a sailboat retrospective for incident reviews?
Yes. The island becomes the service goal or SLO, anchors are what slowed the response, and rocks are latent risks the incident exposed. Use it alongside a written, blameless postmortem rather than instead of one.
Sources
Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020): purpose and timebox of the Sprint Retrospective
Esther Derby and Diana Larsen, Agile Retrospectives: Making Good Teams Great (Pragmatic Bookshelf, 2006): the five phases of a retrospective
Norman L. Kerth, Project Retrospectives: A Handbook for Team Reviews (Dorset House, 2001): the Retrospective Prime Directive
Luke Hohmann, Innovation Games: Creating Breakthrough Products Through Collaborative Play (Addison-Wesley, 2006): origin of the Speed Boat exercise
Betsy Beyer et al., Site Reliability Engineering, Chapter 15: Postmortem Culture (O'Reilly, 2016)
Michael Diehl and Wolfgang Stroebe, "Productivity Loss in Brainstorming Groups: Toward the Solution of a Riddle", Journal of Personality and Social Psychology 53, no. 3 (1987): 497–509
Amy Edmondson, "Psychological Safety and Learning Behavior in Work Teams", Administrative Science Quarterly 44, no. 2 (1999): 350–383
Google re:Work, "Understand team effectiveness" (Project Aristotle findings)