A Template for Effective Retros

Retrospectives are the team’s most valuable meeting. They enable the team to inspect and adapt their ways of working on a regular basis. Small, regular retros bring small, regular improvements to the team. Teams often launch into their retrospective meeting without a plan. The team goes into a room, writes down some thoughts on sticky notes and categorises them into “Good/Bad/Improvement ideas”. Then some (or lots of) actions are assigned and the meeting ends. A discussion is held on each item, actions are assigned and the meeting finishes.

While this can be effective, there is a better way to run retros and maximise their value. Retros usually do not deliver something tangible that is immediately obvious or valuable and so they can be taken for granted,. They are essential for long term growth but teams often feel that they are a ‘nice-to-have’ meeting.

Without well-run retros, your team cannot hope to improve significantly over time as they are removing the main opportunity to inspect and adapt. A good retro should follow the same rules as a good meeting. Think about all of the meetings you attend which are a waste of time. What do they have in common?

They have no goal.
They have no structure.
They have no start or end time.
There are too many people.
They have no output, actions or follow up.

If our retros follow the same bad practices, why should we expect them to be anything but a wasteful meeting?

Below is a template I am developing with teams to run retrospectives. It is largely derived from Derby and Larsen’s expertise in the area, together with some additions I have found helpful for the teams. If you want to deep dive each section of the retro meeting, I suggest to read “Agile Retrospectives: Making Good Teams Great”.

You can copy this template for each retro and refine it over time for your needs.

Template

0. Preparation

Write down the list of actions taken in the previous retro.

Gather the team data to be shown and analysed. For example:

Burndown chart
Velocity
Number of bugs opened
Number of bugs closed
Number of stories completed
Number of stories open at the end of the sprint
Lines of code touched

Tip: Create a Runbook on how to gather each data point above or even better - automate the whole thing for each sprint with a tool like Jira!

1. Set the stage

Welcome

You are all welcome to this sprint's retrospective. The purpose of this meeting is to look back over the last sprint and gather feedback on what went well and what went poorly.

State the Goal

The goal for this retro is to...

General goal: Reflect on the previous sprint what went well and what went poorly.
Refined goal: Improve our teamwork/coding standards/XP practices.

Ask for a Word (Ice breaker)

Ask each person for a quick word. Examples:

Can each person say what their energy level was this sprint (low/medium/high)?
Can each person give a sentence on what they hope to gain this retrospective?
With one word can you describe your mood this sprint?
With one sentence, describe a high point of this sprint.

Plan

Timebox: 90 minutes
Review the last retros' actions and outcomes. Discuss further if necessary.
Show the data.
What was Good/Bad/Ideas/Thank yous.
Actions for next sprint.
Retro of retro.

2. Show the Data

Last Retro’s Actions

List the 1 or 2 actions from the last retro.

Did we accomplish these actions?
Why did we not accomplish them?
Should we permanently add these actions to our ways of working?

Metrics

You should have metrics prepared prior to the retro to analyze with the team. For example:

Burndown chart
Velocity
Number of bugs opened
Number of bugs closed
Number of stories completed
Number of stories open at the end of the sprint
Lines of code touched

Coach your team to look for insights with questions such as:

What problems do we see from this chart?
Are we happy with the number of bugs closed?
I see this bug count doubled from previous sprints. Do we need to do something about that?
Our velocity has halved in the last 2 sprints - do we think this is a problem?

Events/Insights

Ask the team to write down their thoughts for this sprint.

If the retro is in-person, use sticky notes on a whiteboard.

If the retro is remote, use a virtual retro board such as agile.coffee

Use a list of questions to get the team to think about different things. Examples:

What was good/bad?
Big announcements?
Important decisions?
New team members?
Celebrations?
High points?
Low points?
When were you excited to come to work?
When did you dread coming to work?

Tip: Divide the whiteboard into columns such a Good/Bad/Ideas and place the sticky notes in the appropriate column.

Comments

Ask your team to quickly comment on any observations:

Do we see any patterns on these sticky notes?
Are there any surprises that we didn’t expect?

3. Create Actions/Improvements/Ideas

Go through each item and ask questions:

Why did this happen?
What can we learn from this?
What action can we take to keep this going/prevent it in the future?

4. Decide What to Do Next

Ask the team to vote on their top 2 actions they would like to try next sprint.
Create tasks or notes in the backlog for these top 1 or 2 actions.
Assign each action to a person where possible.

5. Close the Retro

Take a screenshot / photo / save the output of the retro somewhere.
Thank you for joining and putting in the effort to this retro and sprint.

Retro of retro

Before closing the meeting, ask your team:

If you could change one thing in our retros, what would it be?

If anything big comes up, setup another call to discuss how to improve your retros.

6. Post-retro Activities

Put the most popular 1 or 2 actions into a backlog item for next sprint.
Record the retro outcome in a document or take a photo/screenshot. You will need to look back at the actions when you prepare for the next sprint’s retro.
Note down any suggestions from the retro of retros.

1 kudos