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.
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:
- Allocate enough time for the meeting. Book an hour at least, you can always leave early if you have finished
- Structure the meeting carefully to ensure the session flows well, from a clear opening through to the definition of actions at the end
- Use engaging (and fun, even) activities throughout the session
- Vary those activities each retrospective to ensure that these regular meetings stay fresh and challenge attendees to look at things from a new perspective
- 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:
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.
Leading Agile Teams 
I think tip (3) – be engaging – is often the hardest and most overlooked element of a good retrospective — especially if they are regular meetings. There is a tendency to treat them as “same old, same old” and do the retrospective on auto-pilot.
Worse, if the retrospective just feels like a “meeting”, there is a tendency to game the process to get it over with. Come prepared with canned actions to get it over with.
Obviously, having a healthy learning culture is the right solution to this problem but tricks to make the meeting engaging and interesting can be a good starting point for businesses that don’t have the right culture.
Do you have exercises that you use or would recommend? That would be a great follow-up blog post …
Thanks for the comment, David. Yes, identifying engaging activities that will ‘work’ with a particular group can be tricky. For instance, teams that are less used to retrospectives can react quite negatively to activities that would be fine for a team that are very familiar with retrospective games.
I’ll certainly post a list of some activities that I’ve used in the past, but team leaders should rely on their insights of their team when selecting something to try.
Hi.. Thanks for the information. Sprint Retrospectives are important and they surely improve the way the team works as discussions during these meetings encompass both what went wrong and what went right. I read another article on Retrospect Sprint Meetings here at -https://www.scrumstudy.com/blog/all-about-retrospect-sprint-meeting/. I hope sharing this links adds to the information you’ve shared.