What Makes a Good Sprint Retrospective?

Reading time: 3 minutes

Earlier today a colleague asked me how I facilitate a Sprint Retrospective. It was her first sprint in the role of Scrum Master and in that sense also her first Retro.

Back to the theory for a moment. The Scrum Guide describes the Retrospective as follows:

“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.”

I must confess that I had to think carefully about how I facilitate such meetings. The past Sprints that I have been able to guide have all gone great with an excellent atmosphere and enthousiastic Developers and Product Owners. Normally I won’t go any further than asking around the questions “What went well? What can be done better? How could it be done better?”.

Sprint Retrospective
Source: https://miro.com/guides/retrospectives/

But as the conversation with my colleague progressed, I tried to look at how one should position one’s self as a Scrum Master within such a Scrum Event. The Scrum Master is a facilitator. I have a few takeaways from my own experiences, that might help you in facilitating a good retrospective.

1. Set the tone

C’est le ton qui fait la musique: it is the tone that makes the music. No matter what happened in a sprint, a lot of work has been done, regardless. That in itself is always something positive to point out. An Increment is delivered through intensive collaboration between Product Owner, Developers (and often the stakeholders as well). You don’t necessarily have to make the disposition more rosy than it is, but it is better to give feedback from a positive mindset than a negative one. Try to break the ice of the Sprint Retrospective with a good positive ‘ice-breaker’!

2. (Transparent) reporting

Although it is not necessarily the role of the Scrum Master to take minutes (after all, you are not a secretary!), it is useful to record the results of the Sprint Retrospective for the next sprint(s). If you don’t do it yourself, perhaps someone else feels the need to take these minutes (but make sure someone does it!). Also share the report with all participants: make the results as transparent as possible!

3. Make the solution as specific as possible

When identifying problems, it is good to find out what the actual underlying problem is. In both “Mastering Professional Scrum” (Ockerman & Reindl) and “Scrum Insights for Practitioners: The Scrum Guide Companion” (Doshi), the Five Whys technique is mentioned as a useful questioning technique. It’s an iterative interrogative technique used to examine the cause-and-effect relationships underlying a particular problem. The primary purpose of the technique is to determine the cause of a defect or problem by asking “Why?” up to five times.

If a problem can lead to a solution (for example, specific action points), then also include this in the reporting.

4. Stay objective

My personal pitfall is that as a Scrum Master I often have a substantive opinion about the product or the process. Combined with my (sometimes dominant) role in conversations, my first reflex is that I often tend to react directly. In recent years I have learned to play the role of a facilitator rather than a participant during a Sprint Retrospective. Think of it as this: you are the person of the questions, not so much of the answers.

5. Stay creative

There are several ways to conduct a Sprint Retrospective. I’ve seen many ways come along: from asking questions using colored M&Ms to imagining the sprint as a sailboat in Miro. Recently, I experimented with evaluating personal learning goals during the Sprint and the Sprint Retrospective (more on that later). What I mean by this is: every team reacts differently to every method. Give yourself the space to experiment! In addition to gaining experience yourself and building up best practices, this also gives the Scrum Team a nice variation in this recurring Scrum Event!

Leave a comment