Sprint retrospectives have in the past proved challenging for me as a Scrum Master:
- Some pigs take an inordinate amount of time to give their feedback. In a team of 8 pigs we often had the first few volunteers getting a lot of bandwidth and short-changing the folks at the back of the queue.
- Discussing all points that are brought up – without sensitivity to relevance and then running short on time to give really burning issues appropriate analysis time. Often there is an underlying feeling that some points are less important than others but out of respect for the pig originating an idea, fellow pigs feel inclined to avoid filtering discussions.
- Some pigs have not done any introspection and try to come up with their feedback on-the-fly – thus doing their fellow pigs who have taken the time to think about things a disservice.
- Scrum Master’s leading rather than facilitating the process (guilty as charged)!
Based on these challenges, I introduced a few process changes to our last retrospective and it made a huge difference. We got rich feedback from all pigs, discussed only the relevant points and had far less Scrum Master interference in the process improvement solution space. Here’s what we did:
(A) Precursors [First 5 minutes]
Elect a Scribe: A scribe was nominated to take points down on the whiteboard. Rule: The scribe at the whiteboard cannot offer an opinion or do any filtering. He/she must simply take down what is being said in a succinct way (the scribe is allowed to ask questions just for clarity). As far as is possible the scribe must use the words of the person making the point – don’t unnecessarily paraphrase. The scribe can be the Scrum Master provided that the rules are followed.
Elect a Timekeeper: The time keeper monitors the timeboxed activities and calls ‘Time’.
(B) Pig feedback: What went well, what could be improved [Next 45 minutes]
- Each pig was given exactly 5 minutes to say in their own words what went well and what could be improved. They could talk about whatever they wanted in these 5 minutes and other pigs were limited to questioning only for purposes of clarity. This also empowers/forces the pig to choose points that are especially relevant if they have a long list of items to go through.
- The scribe takes down the points in two adjacent columns on the whiteboard.
- No discussion is allowed on the topics at this point. Pigs were asked to respect their fellow pig’s right to an uninterrupted opinion.
- Note the scribe being a pig in the team also gets a chance to give his/her feedback and someone else does the scribe duty during this time.
(C) Discussion points voting [20 minutes]
Once the feedback points were captured, each pig was given a distinct color whiteboard marker. They were given 15 minutes to peruse the board and were allowed to make seven votes in total against points that they felt warranted further discussion (you need the distinct color to keep track of your vote count). The number “7” was arbitrarily chosen based on the total number of potential discussion points on the board. Pigs were not allowed to make more than one vote per point thus limiting the potential for any pig to force an issue into discussion (the jury is out on this part).
At the end of 15 minutes, once all votes were cast, we could sum up votes and select the pertinent points for discussion (5 minutes).
Previously we had no aggregated view of topic relevance. The voting mechanism addresses this shortcoming!
"What we can improve" - note the voting marks against the points!
(D) Discussion [60 minutes to 90 minutes]
In this timeboxed period, the pertinent points were explored in order of reducing importance. This ensured that items that were seen to be especially important were not short changed on discussion time.
The scribe would take down any process improvements that came out of the exploration exercise.
(E) Retrospective – knowledge capture [5 minutes!]
Previously I tried to capture notes through the laissez faire discussions that ensued and then retrospectively capture these notes in a document and distribute. As I was often an active facilitator/participant in the discussions I didn’t always have a chance to capture all the relevant points – bad. I also tried on a previous project to record the retrospectives but it was horrible task to have to sit through a 3 hour recording to capture notes retrospectively.
This time was different. Because the scribe had neatly captured the points against “What went well”, “Areas for improvement” and “Process improvements”, capture of the knowledge was simply an exercise in photographing the whiteboards and distributing them on e-mail to the pigs (awesome!).
Crossbolt 
Once all the pigs have provided their input as part of their 5 min discussion, we found it usefull that we elaborate and redifine and rewrite the initially scriibed items into a common language set. This also provides a round whereby we can remove duplicates before voting. Our team is able to use as many votes as they have been allocated against one or more points.
now with spelling corrections 🙂
Once all the pigs have provided their input as part of their 5 min discussion, we found it useful that we elaborate and redefine and rewrite the initially scribed items into a common language set. This also provides a round whereby we can remove duplicates before voting. Our team is able to use as many votes as they have been allocated against one or more points.
Point taken about the common language set. If you look carefully at the photograph, you’ll see some points were scratched off – those were the ones that we realized were duplicates.
Regarding allowing multiple votes against a point – try both ways and see what happens.
Great article
Thanks, man – it’s one way of doing it. Ken (Schwaber) says to mix it up though so that things don’t get boring!