The sailboat retrospective is a model that I especially like to use at the end of significant chunks of work, like a release or the end of an epic or the end of a project. But it could be used at any time, especially if there is a need to better understand project objectives, risks, hindrances and helpers.
I like to use this model for post release retrospectives because it helps the team to focus on lessons learned around unexpected risks, the things that slowed the team down and celebrate the things had really helped us.
A simple retrospective exercise I like to use is the ‘one-word retrospective’ found in Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders. This exercise is particularly useful for helping teams deal with their feelings.
Simply ask every team member to summarize in one word how they felt about the last sprint.
Just as a workman wouldn’t rely on the same tool for every job (unless they have some kind of massive Swiss Army tool), it can be useful for Scrum teams to have a few different retrospective models to draw on. Different approaches help teams to see things from different perspectives.
The starfish retrospective is an extension of the typical three-question retrospective of what went well? what didn’t go well? what could be improved? By asking similar but different questions it can help a team appreciate the practices that are going well as well as consider new ideas. I know scrum masters for whom this is their default retrospective pattern.
“Grey and black boat under grey clouds” by Will Esayenko on Unsplash
I’ve been thinking a lot recently about the size of user stories in agile projects. The idea that I’ve been reflecting on is what if teams only worked with small, similarly-sized pieces of work, rather than exponentially larger blocks of work?
In theory, small user stories should be more predictable, should include less risk, less uncertainty and less complexity. They should, therefore, take less time to complete than larger user stories… you would think! Or as Mike Cohn put it in Agile Estimating and Planning (Prentice Hall, 2006), “small stories keep work flowing”.