All templates

Sailboat Retrospective

The Sailboat retrospective frames the team as a boat sailing toward a goal. Wind pushes the boat forward. Anchors slow it down. Rocks are risks ahead. The Island is the destination. Teams use the metaphor to discuss progress and obstacles in less direct, less defensive terms than a straight Start/Stop/Continue.

What is the Sailboat retrospective?

The Sailboat retrospective frames the team as a boat sailing toward a destination. Wind pushes the boat forward. Anchors slow it down. Rocks are risks ahead. The Island is the destination. Teams use the metaphor to describe progress and obstacles in less direct, less defensive terms than a Start, Stop, Continue retro.

The format originated in agile coaching circles in the late 2000s and spread because it works on whiteboards and remote collaboration tools alike. The visual element matters. People talk differently when they're pointing at rocks and anchors than when they're listing complaints in a column.

When to use it

Use it after a milestone, before planning a new initiative, or when a team needs to step back from sprint-level details and look at direction. It's especially useful when the team has just shipped a release and is about to start something new. The Island column gives the group a structured way to align on where they're heading next. Also good for cross-functional retros where engineers, designers, and product people need a shared frame that isn't loaded with engineering vocabulary.

When not to use it

Skip it for short sprints or when you need fast actionable output. The metaphor adds 10 to 15 minutes of overhead (explaining the four columns, drawing the boat, getting the team into the frame) that may not pay off in a one-week sprint. Skip it also for teams that find metaphors distracting. Some engineering teams will roll their eyes at boats and rocks. Trust that signal and use Start, Stop, Continue instead.

Column prompts

  • Wind — Ask what's pushing the team forward. Tools, people, decisions, structures. Push for specifics: "the new CI pipeline" rather than "good engineering."
  • Anchors — Ask what's slowing the team down right now. Process drag, unclear ownership, dependencies on other teams. These are present-tense problems, not future risks.
  • Rocks — Ask what risks are ahead that the team can see but hasn't hit yet. The holiday hiring freeze, a planned API deprecation, a teammate's upcoming leave. Rocks are about preparation, not blame.
  • Island — Ask where the team is sailing to. The destination, in concrete terms. "Ship checkout v2 by Q3" beats "improve the product." If the team can't agree on the Island, that's the most valuable conversation to have.

Facilitator tips

  • Draw the boat before the meeting. A rough sketch with the four labelled regions takes 30 seconds and saves the team's first 5 minutes of the retro.
  • Start with the Island. If the team isn't aligned on where they're going, the other columns become disconnected.
  • Run silent writing for 5 to 7 minutes. The metaphor needs a moment to settle in before people start writing.
  • Don't let cards drift between columns mid-discussion. If something is both an Anchor and a Rock, ask the author to pick one.
  • End by mapping the top Anchors and Rocks to specific actions. The metaphor is a thinking tool, not a substitute for follow-up.
  • Take a photo of the board if you're in person. The visual artifact is part of what makes this format stick in people's memory.

Common mistakes

  • Wind becomes a thank-you list. Keep it focused on structural advantages, not personal praise.
  • Treating Rocks as "things we don't like." They're future risks, not current complaints. Anchors hold present problems.
  • Skipping the Island. Without a destination, the rest of the metaphor stops working.
  • Spending too long explaining the metaphor. Five minutes is plenty. If people aren't getting it, they probably won't.
  • Walking out without actions. The metaphor produces a clear picture but no commitments unless you map Anchors and Rocks to owners and dates at the end.

FAQ

How long should this retro take?

45 minutes minimum. Plan for 5 to set up the metaphor, 5 on the Island, 10 on silent writing, 15 on discussion across the four columns, and 10 on actions. If you have a larger group, push to 60 minutes.

What if some team members hate metaphors?

Run it once, then ask. Some engineers find the boat distracting and would rather just have the columns named "advantages, blockers, risks, goal." That works fine. You keep the structure of the format without the visual frame.

Can we use this with remote teams?

Yes, it's actually one of the better formats for remote retros because the visual layout gives people something to point at. Use a shared whiteboard tool that lets the team see the boat as they work, and assign one person to keep the visual organised during the session.

Related templates