Making the retrospective more fun !

In many teams I have experienced that the retrospective is a meeting people are not always excited about. Why is that and how can we make the retrospective meeting more fun ?

A typical retrospective is having team members sitting around a table and the question is asked, what went well and what to improve ?
People start scratching their head and neck and after some time the first remarks are made or red notes are put on the whiteboard.
Then long discussions are held how to solve or improve the “to improve” items.
After some time, one hour or even more, the discussions are dried out and the team has to leave the room because the next meeting room reservation is already waiting outside the door.
The thing is that nothing really happens with the “to improve” items.

What is wrong with this approach ?
– Meetings are lengthy.
– Meeting can be dreadful.
– It’s difficult to find solutions in just a single meeting.
– Not everybody participates with the same enthusiasms.
– Many times the meeting produces no outcome or result.

How to avoid this ?
Approach the retrospective meeting as a short game with a playground, actions, artifacts and goals.
Make the retrospective short and dynamic, without lengthy discussions.
The amount of time people can give their maximum attention is about 20 to 30 minutes, so this should be the length of the retrospective.
The possible improvements that people come up with can be wishes or so called fuzzy goals, it doesn’t matter, anything is possible.
Try to find actions that can lead to (small) improvements instead of finding complete solutions.
Important is to realize that many “to improve” issues are wishes, and wishes can’t be tracked or measured on success. Always translate wishes to goals and actions.
For example a to improve item can be : “communication with customer”. Try to define actions that will lead to small steps of improvement for example : setup a meeting with the customer to brainstorm about this or ask the customer’s opinion about spending one or more days per iteration with the development team.
So, how does this retrospective game look like ?

A whiteboard is the playground (dedicated white board !)
Artifact, Actions
An important artifact is a so called Who/What/When matrix, this can be a sheet with three possible improvements and their supporting actions to get closer to these improvements and the names of the persons who will do the actions and when these actions will happen or are due.
The goal of the retrospective is to find the three winning possible improvements :
“To improve items” and “Went well items”.
The three possible improvements are a result of a voting game where people can give 5 points in total to possible improvements.
The ultimate goal is to successfully close all actions on a Who/What/When matrix at the end of the iteration.


A volunteer can lead the retrospective preferable like a stand-up

In practice
The team gathers around the whiteboard and writes on post-it’s what they think that did not go well during the iteration, the “to improve items” and the things that “went well”
Better is when the notes are already put on the whiteboard during the iteration so time is not wasted thinking of subjects during the retrospective.
Different notes sharing a common subject are gathered to make issues more visible.
Every note/common subject is introduced by a volunteer and a small discussion is held for a maximum of 3-5 minutes
5 points can given by each team member. A maximum of two per note can be used to avoid veto votes.
The 3 winning “to improve” items with the most points are written down on the Who/What/When matrix.
Just a small discussion is held about the three winning “to improve” items what actions can be taken to make a (small) step to reach the goal.
One of more volunteers can attach their name to one of the three subjects to define actions during the next iteration that can be taken to improve the winning “to improve” items.
These actions must be done in the next iteration. Important is that they don’t have to be solutions, just a small step towards the solution is enough.
Actions can be :
Organize a meeting to discuss ….
Write an email to ask …..
Look for a tool that can help with ……

The “went well” items are also important in such a way that they can be used as :
How can we make sure that in the next iterations these items continue to go well or how can we let other teams also benefit from our knowledge to make these items go well.
An idea is to discuss two or more times in the next iteration the Who/What/When matrix and discuss the progress of the actions.
After the sprint review the subjects on the matrix can be closed, the ultimate goal of the game.
High score, game over !

Feature costs

Refinement of the product backlog will tell how many user stories a feature consists off.
Team guesstimates how many iterations it will take to deliver the user stories for this feature.
The “manager” (should) know the (average) cost of the team per iteration and therefore the total costs of the feature can be guesstimated.
Easy not ?
Or is it more complicated….. ?

Feature cost