The sprint retrospective – why is it needed and what are best practices?

Along with the refinement, I find the sprint retrospective to be the most important ceremony within the Scrum Framework. It embodies one of the main features of agile product development, iterative improvements. This is, in my view, at the heart of agile product development. Iteratively improving not only applies to the product itself but also to the developmental process, the method of collaboration, and used frameworks. 

Agile product development means regularly shipping product increments and reacting on user’s feedback. It also means regularly reviewing how we are developing and adjusting the things that don’t work. The Scrum method institutionalizes these regular reviews with the sprint retrospective – or retro for short. 

This is what I will focus on today. I will first explain why the retro even exists, what it looks like, and finally share some of the best practices I have found to be essential for the ceremony to be effective.

Email address:

Leave this field empty if you're human:

The goals of the sprint retrospective

On the surface and stated above the main reason for having a retrospective is to understand what is working and what is not. The goal is for the team to reflect on the processes, on collaboration amongst themselves and with other teams, and on their relationships. The goal is to celebrate what is working and understand if things that are not working need to be and can be changed.

One level deeper, if you really think about it, the retro is all about team building and chemistry. If used correctly the retro is an effective tool that helps create a positive atmosphere and satisfied team members.

Moreover, it helps create buy-in in the used development methods and tools. It is the place to propose changes. Since the proposals and decisions on those changes come from the team itself, it creates a sense of ownership and thus buy-in to the used product development process.

All of this together means that the retrospective is an effective tool to help create a motivated, high performing team. Its importance in this regard cannot be overstated.

How does the sprint retro look like in practice?

Having established why a retrospective exists I will introduce how it actually works. In the end, it is nothing more than regularly reflecting on our work. 

In this context, I want to emphasize three points that in my view are fundamental to making the ceremony effective: the five steps that make up a sprint retro, its frequency, and the desired atmosphere.

The five steps that make up a sprint retro

There are generally five steps to go through in the retrospective. It’s not overly complicated and pretty straight forward. The difficulty lies in the (potentially) hairy topics that need to be solved. 

1. Open action items
2. Collect thoughts
3. Share and cluster
4. Decide on what to talk about
5. Discuss and create action items if needed

First, we tend to check the open action items from the last retrospective and hopefully mark all of them as done.

The second step is actually collecting all topics to discuss. This is timeboxed and each team member should individually write down anything that comes to mind. There are plenty of facilitation techniques to use for this brainstorming step. I personally enjoy the 4 Ls, the Starfish, or the Sailboat. Sometimes, we simply go with two categories: what worked and what didn’t. 

In my view, the technique is not that important, but it is important to vary the techniques. I believe this keeps us mentally on our toes and avoids monotony. It helps us think differently and makes us more creative instead of going through the same motions over and over. Also, more mature teams might not even need any of the techniques. They simply address what is on their mind. 

The third step is everyone sharing their topics. We do not yet discuss the topics at this point. But I do generally try to clarify if it is clear what is meant by what is written.Then, we cluster similar topics. 

Fourth, everybody votes on what they want to discuss. Dot-voting is probably the most frequently used technique here. Lastly, the team discusses the topics and we create action items with a responsible person if it is needed.

There is a lot of great software out there suited for sprint retrospectives. Retrium is the one we used most in the past. For fully in-person retrospective (yes, they do still exist and are extremely effective!) all that is needed are pens, post-its, and a white board.

One additional point to mention about more experienced teams. The more mature the team is, the more familiar the team members are with one another, the less the five step structure from above is needed.  They are a great structure to use. However, mature teams are able to discuss problems without needing this structure. The team members feel when something is wrong and don’t hesitate to address it. 

In the end, as always with agile development, it’s important to use whatever works best for the team. 

The frequency 

The retrospective is regularly taking a step back and reflecting on how we are working. The important word here is regularly. It happens at a consistent frequency. For most teams it takes place after a sprint is completed. With teams I have worked with in the past we generally conducted our sprint review first, then took a short break, and afterwards went into the retro. 

Some teams decide to conduct the retro less frequently. This is fine as long as it still happens regularly and the period between retros isn´t so long that the team can’t remember what happened. In my view, after every sprint is best, every two sprints is still ok, and everything longer is too low of a frequency.

The atmosphere: a safe space

The retro must be a safe space where any and all issues, problems, or achievements can and should be openly discussed. For this reason the participants are limited to the team and the Scrum Master. That’s it, no one else needs to be there. This ensures a familiar atmosphere where – after some time of getting to know each other – most team members feel comfortable openly sharing issues.

It can happen that stakeholders want to join the sprint retrospective. I strongly advise against that. The sprint retrospective needs to be a safe space where people are familiar with each other. This will not happen if other people, possibly from management, occasionally join. If they insist on joining, I tend to create a separate, one-time retrospective where that person can join and we jointly reflect on a specific project or topic.

The regular retrospective after each sprint with only the team and Scrum Master is sacred. Only by keeping it this way can you create the safe space to also discuss difficult topics when needed.

My best practices to make the sprint retrospective effective

I want to share three best practices that I have found to help ensure that the retrospective is and remains effective over the long run.

• Keep the brainstorming short and the discussion long
• Walk the walk
• Leadership, empathy, and understanding

Keep the brainstorming short and the discussion long

The valuable parts of the sprint retro are the discussions and what comes out of them. Thus, we should maximize the time for those. Since the retrospective as a whole is timeboxed, maximizing the length of discussion means minimizing the duration of the other steps.

I find that particularly true for the brainstorming part of the retro where we collect our thoughts and topics. Far too often do I see teams spending ten, fifteen, or even more minutes on that part of the retro. Three to four minutes is enough, even two works most of the time! 

The most important topics are the ones that come to mind first anyway. Those are the ones we need to discuss. If any truly important topics are forgotten, we can always add them later (it rarely ever happens, trust me). Keep the time for idea gathering short, so you have more time to actually discuss solutions.

Walk the walk

This is straightforward. Whatever is decided in the retro needs to actually be executed or implemented. If not, the ceremony quickly turns into a paper tiger. Team members just end up going through the motions because they know nothing will come as a result anyway.

It is mostly on the Scrum Master to follow up on the action items, particularly for inexperienced teams. However, the team also has a responsibility to hold the members themselves responsible for completing the action items.

Leadership, empathy, and understanding

Within the retro we often discuss difficult topics: conflicts between team members, problems with our way of working, our other sources of unhappiness. This is by design and a good thing. Those topics need to be addressed. However, they are by their nature not pleasant discussions. 

Leadership skills are crucial in those critical discussions. We need to really listen, create empathy, and try to understand where the complaints are coming from. Only then can we try to jointly find the solutions. This can be extremely difficult!

Hopefully, the Scrum Master has the skills to maneuver these difficult situations. In my experience this is actually very rarely the case and I always encourage the team members to help out here if needed. 

It’s generally a tough balance to strike for the Scrum Master between trying to solve all problems for the team and teaching/encouraging the members to do this themselves. The Scrum Master is generally the one to facilitate and remove impediments. However, it’s a slippery slope when the Scrum Master tries to solve everything.

All of a sudden we get this dynamic where the team simply comes to complain and expects others to solve their problems. It’s important to remember that this is a joint responsibility of the entire team. Again, leadership skills are extremely important in striking this balance.

One final point, In case extremely serious things come up in the sprint retrospective – think personal conflicts that you cannot seem to solve – don’t hesitate to get outside help. There are topics that are too much to handle for anyone. In this case – after aligning with the team, there is absolutely no shame in getting help to try and resolve these issues. 

Retrospectives make sense in any context

The sprint retrospective is a ceremony within the Scrum framework. It ensures that the team regularly reflects on how they are working. It is the embodiment of the final principle in the agile manifesto.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I would argue that this principle is almost universally true. For this reason, I strongly believe that conducting retrospectives makes sense in all kinds of situations. It makes sense in other forms of product development, in project management, in team building, within personal relationships. 

All of these benefit from regularly reflecting on processes and relationships and seeing how you can improve, whether you´re using Scrum or not.

Coverphoto by Ross Findon auf Unsplash