The Sailboat retrospective: wind, anchors and rocks
By Scrumagic Team Last reviewed 6 min read
In short
The Sailboat retrospective uses a picture of a boat heading for an island, with wind pushing it forward, an anchor holding it back and rocks ahead. It gets teams talking about forces and risks instead of events, and it ties the discussion to the goal. It works best when a team is stuck in blame or complaint. This post shows how to run it, with a worked example and cautions.
Some retrospectives go wrong because the format invites the wrong kind of talk. A column headed "what went wrong" collects complaints. A picture with a destination, helpful forces and hazards collects something else: an account of where the team is trying to go and what is affecting the trip. That is the idea of the Sailboat, and it suits a team that has been circling the same frustrations.
Where this format stands
No source defines the Sailboat. The Guide says what the Retrospective is for, to plan ways to increase quality and effectiveness, and asks the team to inspect individuals, interactions, processes, tools and the Definition of Done, identify the assumptions that led it astray and explore their origins. The method is left open. A vendor guide to retrospectives advises that varying the format is useful while keeping timing and attendees consistent. The Sailboat is a well-known variation, widely used by teams and facilitators, with several versions in circulation. Treat the description below as one version.
The picture
Draw a boat on water, with an island in the distance. Add four elements.
The island. Where the team wants to be. For a Sprint retrospective this is usually the Sprint Goal or the Product Goal, or a team goal such as "releasing every Sprint without drama".
The wind. What is pushing the team toward the island. Strengths, helpful habits, good support from stakeholders.
The anchor. What is holding the team back. Slow reviews, unclear requirements, a flaky test environment.
The rocks. Risks ahead that could damage the boat. A deadline, a dependency, a person leaving, a regulation changing.
Some facilitators add a sun for what is working beautifully, or a storm. Keep it to what the team can use. More elements mean more cards and less discussion.
How the format differs from others
Start, Stop, Continue asks what to do. The Sailboat asks what is happening to the team, which can be a gentler way into hard topics. It is also forward-looking through the rocks: the team is invited to name risks before they arrive, which the Guide's focus on adapting early supports. And it is anchored to a destination, so comments are measured against something the team cares about. See the Start, Stop, Continue retrospective for a simpler comparison.
How to run it
A one-hour version for a two-week Sprint:
- Draw and explain (5 minutes). Draw the picture and agree what the island is. Without a shared island the rest is hollow.
- Silent writing (10 minutes). Each person adds cards to wind, anchor and rocks.
- Cluster and read (10 minutes). Place cards on the picture, grouping similar ones. Read out each group.
- Pick the anchors and rocks that matter (5 minutes). Dot-vote. The team can only change a few things.
- Decide what to do (25 minutes). For the top anchor, find a way to lift it, even partially. For the top rock, decide whether to avoid it, prepare for it or accept it. For the wind, decide what would keep it blowing.
- Close (5 minutes). Read back the actions, owners and the day they will be checked.
A worked example
This is an illustrative board from a team that is eight weeks into a payments project and feels it is losing momentum.
The island: "go live with the first payment type by the end of next month".
| Wind | Anchor | Rocks |
|---|---|---|
| The Product Owner answers within an hour | Test environment resets every night | The bank's testing window closes in six weeks |
| Pairing on the integration | Reviews wait more than a day | Only one person knows the settlement file format |
| Support staff attend the Review | Acceptance criteria change after work starts | A new regulation notice due next month |
In the cluster step, the team notices that two anchors and one rock are about one person's knowledge, because the nightly reset wipes the settlement data only that person knows how to rebuild. They vote that cluster most important.
The actions: record the settlement file steps as a short guide within the Sprint (owned by the person who knows), pair a second person on the next related item, and ask the platform team to stop the nightly reset for the team's environment, with the Scrum Master to raise it with them. For the testing window, the Product Owner will confirm the exact date and share what the team needs to prepare.
The retrospective produced three actions and a shared view that the real risk was one person's knowledge, which no one had said so directly before.
Cautions
A metaphor can fall flat. Some teams find boats silly, and others enjoy the lightness. If the picture distracts, use plain headings: "helping us", "holding us back" and "risks".
The island must be real. If the team cannot agree on a destination, the discussion drifts. Spend longer on this step if needed.
Rocks need follow-through. Naming a risk is only the first step. Each top rock should get a decision.
Watch for blame. Anchors can slide into naming people. The Guide describes the Retrospective as a chance to inspect individuals and interactions, which is easy to misread as permission to criticise someone. Keep the focus on the system. If personal issues arise, deal with them privately.
Do not stop at wind. Teams in a good phase may fill the wind with praise and skip the anchors. Ask what would make the wind stronger.
Adapting it to a short Sprint
On a one-week Sprint there is little time for a full picture. A short version keeps the island and uses only two prompts, "what is pushing us" and "what is in the way", then spends the rest of the time on a single action. For a team that has just finished a larger release, the opposite is better: widen the island to the whole release, add the rocks that remain ahead, and take the time that the Guide allows. The format is flexible enough to carry either.
It also works well as a mid-project check. At the half-way point of a long effort, the question "are we still heading for the same island?" often exposes a drift that Sprint-sized retrospectives, with their focus on the last two weeks, miss. If the island has moved, that is information for the Product Owner and the sponsor, not a problem for the team to solve alone.
Common mistakes
- Overloading the picture with extra symbols.
- Leaving with ten actions.
- Using the format every time. The Sailboat is best for a change of perspective, and repeated use makes it routine.
- Forgetting to check last Sprint's actions at the start.
Two perspectives
Neither source prescribes this, so practice varies.
Scrum Guide
The Scrum Guide gives the Sprint Retrospective the purpose of planning ways to increase quality and effectiveness, inspecting people, interactions, processes, tools and the Definition of Done, without naming any format.
SBOK®
The SBOK® Guide describes the Retrospect Sprint meeting as a discussion of what went well and what did not, producing agreed actionable improvements for the next Sprint, and also leaves the format to the team.
Same thing, different words
- Sprint Retrospective (Scrum Guide) = Retrospect Sprint (SBOK)
The Sailboat is a facilitation technique with several versions. Neither source defines it, so the version here is one reasonable reading.
How to practise it
Draw a boat for your own team and try naming one anchor and one rock without naming a person. In the simulator, the retrospective at step 4.2 asks you to think about what holds the team back and what to change, which is the same question in a different shape.
Sources
- The 2020 Scrum Guide, Scrum Guides. Read on 14 October 2026.
- What are agile retrospectives?, Atlassian. Read on 14 October 2026.
SBOK® is a registered trademark of its owner. Scrumagic is independent and is not affiliated with the owners of SBOK®.
Nothing opened? This computer may have no email program set up. Write it in Gmail or use the copy button and paste the link into your email.