Five steps to an effective sprint retrospective

In a typical agile software development process, sprint retrospectives are meetings run at the end a development iteration. In those sessions the team looks back on what they have done and how they have done it, and decides what they can do to improve. More succinctly, the team inspect and adapt.

Inspect and Adapt

In my experience, sprint retrospectives are invaluable and the most effective, timely and action-focus form of ‘review’ meeting. If run right, these meetings can be the life-blood of a development team – encouraging them to habitually build on successes and address problems.

However, sprint retrospectives can be tricky to run ‘right’ and as a result, they can be ineffective. An ineffective retrospective might be shallow – only looking at surface issues and not root causes – or it may even forget the adapt part of “inspect and adapt”.

Here are five things you can do to increase the likelihood of running an effective sprint retrospective:

  1. Allocate enough time for the meeting. Book an hour at least, you can always leave early if you have finished
  2. Structure the meeting carefully to ensure the session flows well, from a clear opening through to the definition of actions at the end
  3. Use engaging (and fun, even) activities throughout the session
  4. Vary those activities each retrospective to ensure that these regular meetings stay fresh and challenge attendees to look at things from a new perspective
  5. Be tenacious when it comes to creating a small number of concrete, actionable tasks at the end of the meeting. These actions are the real value of the retrospective – the teams adaptations and the mechanism through which they will improve.

I’d recommend doing all those things, but I’d like to focus on how to structure the meeting.

Below is a retrospective structure popularised by Esther Derby and Diana Larsen in their book Agile Retrospectives. It has five sections, each with a specific goal.

  • Set the stage – Goal: Set the tone and direction for the retrospective
  • Gather data – Goal: Create a shared memory; highlight pertinent information and events
  • Generate insights – Goal: Think creatively; look for patterns, themes and connections
  • Decide what to do – Goal: Generate and prioritize valuable, clear actions
  • Close – Goal: Summarize and end the meeting

For each section of the meeting, you should plan an activity (sometimes something as simple as each person saying one word) that meets the requirements for that section and progresses the team along their mission to “inspect and adapt”.

I like to visualise the meeting like this:

Retrospective structure

Once you become familiar with the stages of the retrospective and what needs to be achieved, it’s fairly easy to come up with new activities (on variations on existing ones) to make your retrospectives feel fresh. As an example, in an upcoming post I’ll outline a quick activity I came up with to gather data in a recent sprint retrospective I ran with my team.