A Beginners Guide to Sprint Retrospectives

The Scrum Guide defines the retrospective as an event where “the Scrum Team identifies the most helpful changes to improve its effectiveness.” However, it does not say how a retrospective should be structured or how this event is run in detail. Therefore, newly certified Scrum Masters or beginners in Scrum often wonder how to actually conduct a retrospective. This article provides a brief introduction to how Scrum retrospectives are conducted.

Meaning and Purpose of Agile Retrospectives

As already mentioned, the Scrum Guide defines the retrospective as an event in which the Scrum team has the opportunity to review itself. As a result and in relation to the three Scrum pillars, it should define actions on how to improve. You could say that the Retrospective is the “organizational twin” of the Sprint Review. While the Sprint Review focuses on reviewing and adjusting the increment (the product), the Sprint Retrospective focuses on reviewing and adjusting everything related to the Scrum Team (the organization).

The Sprint Retrospective generates insights about the Scrum Team itself, the processes that have been established and are operated in the Scrum Team, and the team’s relationships with the outside world. Thus, it increases transparency about organizational aspects of the Scrum Team, which enables alignment. It also promotes the values of the agile manifesto, as it increases interaction and, through resulting process improvements, increases the quality of the increment and customer value.

The six Steps of a Retrospective

If you are new to Scrum or have just started your agile journey, it may be hard to imagine how a Sprint Retrospective needs to be structured to deliver the outcomes mentioned in the Scrum Guide. All we know is that the Scrum Master needs to keep the event within the timebox, ensure that the team is participating in the meeting, and that it is their responsibility to encourage the team to strive for improvement in terms of the development process and practices.

While it would be possible to hold such an event as an open discussion of what went well and what didn’t, this is unlikely to produce the necessary results. Remember that at the end of the retrospective, at least one improvement is supposed to be included in the Sprint Backlog of the next Sprint. Therefore, it is critical to examine what went well, and more importantly, what did not go well. Analyze why it happened and then define actions to change, improve or fix the underlying cause.

1. Introduction

The first step of any retrospective should be a short opening by the Scrum Master. He welcomes the team to the event and gives a short introduction about what will happen during the retrospective.

At this point he should also address, what is called the Las Vegas rule.

What is said in the room stays in the room. There is no exception from this rule.

(Unless, of course, it is identified as an improvement and placed in the Sprint Backlog or Product Backlog. This is possible for improvements that cannot be addressed in the next Sprint as long as there is at least one improvement that will be addressed in the next Sprint).

He should also mention the prime directive of software development, a.k.a. the “no blame rule”.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Finally, the Scrum Master presents a timebox agenda of upcoming games, techniques, and discussions that the team will conduct during the retrospective.

2. Setting the Stage

After the rules of engagement are set, it’s time to set the stage. At this stage, the Scrum team arrives at the retrospective. Most likely, the sprint review has just ended and each team member arrives at the event with a certain mood and mindset. It is critical to activate all team members to actively participate in the meeting.

Therefore, the beginning of a retrospective typically consists of activation exercises. There are many such mini-games. Whatever game or exercise is chosen, it should give each team member the opportunity to speak up and participate. In this way, the team can actively tune in to the upcoming retrospective.

3. Gathering Data

During the next stage data about the last Sprint is gathered. In the Scrum Guide, this step is described as the point where …

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.

It is important that all team members actively participate in the collection of this data. The Scrum Master can refer to the Scrum values of openness and respect as well as the Prime Directive.

Often, this step is done by having everyone write their thoughts, reflections, and observations about the last sprint on post-its. Then these post-its are collected on a flipchart or whiteboard. Typically, each team member sticks their own post-its on the whiteboard and provides a brief explanation to create a common understanding.

The Scrum Master steers this process in a sensible direction and helps the team to cluster the various points. The team then decides by voting which two or three clusters should be discussed in more depth. The winning topics of the voting are carried over to the next phase of the retrospective.

4. Generating Insights

The biggest pain points have been selected by the team and are now discussed in detail. The goal is to identify their root causes. This is typically the most strenuous part of the retrospective. It requires complete openness and courage from all team members, as well as focus and respect, and a willingness to actually track down the root causes.

There are a lot of exercises that can be used to do this step effectively. E.g. “The 5 Whys” where each issue is explored deeper and deeper by asking “Why did this happen / is this happening?” and in the end the root cause is found. Another very popular method to discuss the identified issues is the Lean Coffee.

5. Decide What to do

At this point, the team has tracked down major points that should be improved, but however, the most crucial step is still missing. The Scrum Guide states that …

The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

In other words, this is the point at which the actual measures for improvement are defined. this can be done as an open discussion or brainstorming session. Whatever suits the team best is allowed.

After the discussion is over and the measures are clearly formulated and approved by the team, there is only one thing left to do. The team enters at least one of the identified actions into the Sprint Backlog. If some of the actions cannot be addressed in the next Sprint, they can be placed in the Product Backlog. (But even if they are, it doesn’t allow the team to skip the next retrospective).

6. Closing the Retrospective

At this point, it is not uncommon for team members to feel exhausted. A retrospective that really focuses on identifying and defining areas for improvement is an intense and energy-sapping event. Team members are likely eager to leave the retrospective and get back to work.

Nevertheless, the retrospective should be closed properly. Here, the Scrum Master has the opportunity to gather feedback on the various aspects of the retrospective. This can include the current emotions of the team as well as feedback on the moderation of the event by the Scrum Master himself.

As the last step of the retrospective, the Scrum Master closes the retrospective. This marks the end of the sprint. I like to use this opportunity to welcome the team to the next sprint and wish them a lot of fun and success for the upcoming work.

Preparation of a Retrospective

If you are new to the role of Scrum Master, it can be quite a challenge to prepare a retrospective. You may think that you are not up to the task. Remember: every Scrum Master has had to hold their first retrospective at some point. Approach it simply and take it as an opportunity to practice and learn. Holding retrospectives every sprint will help you grow in your role. As we know, practice makes perfect, and a sense of inspection and adaptation can help.

But even experienced Scrum Masters need to prepare for a retrospective. This includes reflecting on the last sprint and how it went in terms of people, processes and tools. This can help select the right techniques, games or building blocks for the retrospective. After you have selected an exercise for each step of the retrospective, it is time to draw some flipcharts.

The flipcharts not only help visualize the retrospective, they also serve as a focal point. You can always lead the discussion in such a way that you come back to these flipcharts. This will improve the team’s focus and lead to much better results. During the retrospective, you can write on these flipcharts or stick post-its on them.

Besides the flipcharts you need enough equipment to actually perform the retrospective (pens, post-its, magnets, stickers, a stop watch), and don’t forget: a place to hold the retrospective at.

Alternatively, if you are conducting a virtual sprint retrospective, you can use one of the many existing online tools for this purpose. However, this does not mean that it is not necessary to prepare thoroughly for the retrospective.

Final Thoughts

At some point in their career, every Scrum Professional has participated in their first Sprint Retrospective. If you were not a member of a development team or Product Owner before becoming a Scrum Master, this can be an intimidating event. Don’t hesitate and learn how to conduct a sprint retrospective. It’s not rocket science, but it does require preparation, communication, and a lot of insight and adaptation. There are plenty of books out there that can help you choose the right techniques and games for a successful retrospective.

Finally, when you learn how to effectively structure and facilitate a Scrum Retrospective, you will not only become a better Scrum Master, but also make your entire team a better Scrum Team.