Sailboat Retrospective

What is the Sailboat retrospective?

The Sailboat retrospective looks at the team as a boat trying to reach an island. Wind pushes it forward, anchors hold it back, rocks ahead threaten it, and the island is where the team is trying to get. Four questions, one metaphor, and a board that covers the past and the future in the same picture.

What separates Sailboat from most retrospective formats is the rocks column. Went Well / To Improve, Mad Sad Glad and 4Ls all look backwards; Sailboat forces the team to name risks that have not happened yet. That is why it is the format teams reach for before a release rather than after a routine sprint. The metaphor also gives people a safe way to raise an uncomfortable risk: naming a rock in the water is less confrontational than predicting that a colleague's plan will fail.

When to use the Sailboat retrospective

• At the start of a project or a quarter, when the destination still needs to be agreed and written down.
• Before a release or a migration, when unnamed risks are the main thing that will hurt you.
• When the team is busy but not obviously moving — the anchors column makes accumulated drag visible.
• After a reorg or a change of direction, when different people are quietly rowing towards different islands.
• With a mixed audience — stakeholders, designers and engineers all understand the metaphor without an agile glossary.
• When routine retrospectives have gone flat and the same three process complaints keep reappearing.

It is a poor fit for a short, calm sprint with no risk on the horizon: four columns for a two-week increment is more structure than the material justifies. It is also the wrong format when the team needs to work through a single incident in depth.

The columns explained

Wind — what is pushing us forward

Practices, people, tools and circumstances that made the team faster. Pairing that spread knowledge, a test suite that caught regressions, a product owner who answered questions within the hour. Wind is not a compliments round: each card should name something the team can deliberately keep doing. If a card cannot be repeated on purpose, it is luck, not wind.

Anchors — what is holding us back

Everything that adds drag: a flaky test suite, an approval that takes three days, unclear ownership of a service, meetings that consume the morning. Anchors are the column that produces most action items, because most of them are things the team can cut without permission from anyone else.

Rocks — risks ahead

Dangers that have not hit yet but will if nothing changes: a dependency with a single maintainer, a key person going on leave during the release week, a deadline nobody has re-planned since the scope doubled. Rocks are the reason to run this format. For each rock worth keeping, decide whether you steer around it, remove it, or accept it and say so out loud.

The island — where we are going

The goal the boat is sailing to: the release, the quarterly objective, the state the team wants to be in. Fill this column first. Wind, anchors and rocks are only meaningful relative to a destination, and it is common for a team to discover here that four people would describe the goal four different ways.

Example board

An eight-person team ran Sailboat six weeks before migrating a payments service to a new provider.

The island column was the surprise: half the team assumed "migrated" meant traffic switched, the other half assumed the old integration would be removed. Writing it down changed the estimate. Two rocks became scheduled work — a rollback rehearsal, and a refunds walkthrough recorded before the leave started — and the cutover was moved one week to clear the finance close.

Timing for a team of 5–10

Facilitator prompts

• Island: "If this goes perfectly, what is true in eight weeks that is not true today?" — "Would everyone here describe the destination the same way?"
• Wind: "What made us faster that we could deliberately do again?" — "Who or what saved us time this month?"
• Anchors: "What did you wait on?" — "What do we do every week that adds no value?" — "Which of these could we cut without asking anyone's permission?"
• Rocks: "What would make us miss the date?" — "What are we assuming will hold?" — "What has gone wrong on projects like this before?"
• On a rock: "Are we steering around it, removing it, or accepting it? Pick one out loud."

Common mistakes

• Leaving the island vague. "Ship the migration" is not a destination. Without a specific end state, the other three columns collect generic material and the session drifts.
• Filling the island last. Teams that start with wind and anchors end up describing the sprint they just had rather than the journey ahead.
• Collecting rocks and never deciding. A named risk with no decision attached is worse than no retrospective, because the team now believes it has been handled.
• Letting anchors become a list of other departments. Some drag is external, but a board where every anchor belongs to someone else produces no action the team can take.
• Spending the whole hour on the metaphor. Nobody needs an illustration of a boat. The four questions are the exercise.
• Using it for every sprint. Four columns and a risk round are overhead for a routine two-week increment. Save it for project starts, releases and quarterly checkpoints.

How to run the Sailboat retrospective in QRetro

1. Create a board from the Sailboat template — wind, anchors, rocks and the island are already set up.
2. Share the link; participants join in the browser without an account.
3. Agree the island first and write it on the board before opening the other columns.
4. Run one silent round for wind and anchors, then a separate round for rocks.
5. Reveal, group duplicates, and give each person three votes.
6. Work through the top anchors and rocks, and record an owner and a date for every decision.