Last week I ran a retrospective which focused on the effectiveness of our estimation meetings with the aim
of producing working agreements. Until recently our Scrum retrospectives just looked at the work completed in the last sprint and had become a bit repetitive. Reading Agile Retrospectives gave me a great insight into how to structure and run an effective retrospective. It also contains a great reference for exercises that can be used in each stage of a retrospective. I came up with a session plan and prepared all of my resources in a couple of hours.
The structure I followed from Agile Retrospectives was:
- Set the stage
- Gather data
- Generate insights
- Decide what to do
- Close the retrospective
Everyone in a retrospective should feel free to contribute to the discussion. The idea is to do this by getting everyone to speak at the beginning of the meeting. I did this by asking everyone to briefly mention (in 20 seconds) the best and 'not so good' estimation meetings they had been to (in the spirit of the retrospective prime directive). I also outlined the aim of the meeting.
During the sprint we reviewed our completed User Stories to see if the points estimate was 'Too Low', 'Too High' or 'OK'. This gave us some data on which to base one of the group exercises and create discussion. We also ran an activity called Satisfaction Histogram which helped to both set the stage and gather data. I asked 'How satisfied are we with planning meetings?' and 'How satisfied are we with the release?'. The results were positive for the release but not good for the planning meetings; this also confirmed for me that I had chosen the right focus for the retrospective.
We generated insights by splitting into two groups, one looking at the reviewed User Stories and the other at experiences of previous planning meetings. After the groups had finished both exercises, they each presented back their thoughts.
As a whole group, we then put all the ideas we had generated on a flip chart. This resulted in 12 potential working agreements. This was too many for us to be able to use sensibly, so I ran a dot vote with the aim to get the top 5; everyone had 3 votes. We decided that our new working agreements for estimation meetings are:
- Clarification of story details by Product Owner is OK, debate is not
- Don't be afraid to use the '?' card in planning poker
- Only high/low estimators speak in planning poker
- Everyone should focus on the discussion and be ready to estimate
- There should be fewer tickets in any one meeting
Agreement four could be helped by introducing the 'I need a break card' so that people feel able to interrupt the meeting if they can't concentrate. Five isn't really an agreement but a change that we need to ensure we have productive meetings.
I am not sure I closed the retrospective very effectively, so you can consider this statement my retrospective of the retrospective. I'll try to do this better next time.