What is a Sprint Retrospective in Scrum?
The Sprint Retrospective is the last event in every Sprint. During the Sprint Retrospective, the Scrum Team looks back at the previous sprint and identifies possible improvements.
The Scrum Master facilitates the Sprint Retrospective using a format that enables the team to think of the things that went well, can be improved, and convert these into one or more actionable items that the team will commit on during the next sprint.
Who should participate in the Sprint Retrospective?
The entire Scrum Team should participate in the retrospective. I often see teams not inviting their Product Owner to the retrospective because they are a bit less involved in the team working. This is not the right way to go, a team should always strive to maken the Product Owner fully part of the team and thus also invite him/her to the retrospective.
Sometimes it can also be valuable to invite other stakeholders to the retrospective. I’ve seen teams invite members from other Scrum Teams to their retrospective to reflect on the cross team elements together. This is a good example of a mature team.
How do you facilitate a Sprint Retrospective?
Every retrospective contains the following stages:
Setting the stage
Start your retrospective with setting the stage, breaking the ice and getting everybody ready to reflect on the past sprint. People often have a busy day and need to “land” in the retrospective to be fully engaged and open to reflect on the last sprint.
There are many formats for setting the stage in a Sprint Retrospective. An exampe is the temperature gauge, but there are really a lot of possible formats you can use here.
We have a full retrospective toolbox on this website where you can find many formats for setting the stage. Most formats are exportable so you can use them right away!.
Gathering data
After the stage is set and everybody is fully present and ready to retrospect, we should gather some data. During this stage I like to use a format that allows team members to think of topics from the last sprint that they would like to discuss, change or improve.
Using different formats keeps it interesting for the team. If you always use the same format, the inspiration will be gone after a few sessions.
The default approach is to start a timer for 5 or 10 minutes and give everybody time to write down topics that they would like to address in the retrospective session. During this stage, they should just write down things (individually or in pairs, depending on the format you are using) without having a discussion. If something that is written down is not clear, people can ask for a short explenation but you should avoid having discussions about the topics just yet. The goal is that everybody has time to come up with topics that they want to discuss with the team.
When the timer is finished, and everybody had the chance to write down the topics that they want to discuss, you can move on to the next stage: generating insights.
We have a full retrospective toolbox on this website where you can find many formats for setting the stage. Most formats are exportable so you can use them right away!.
Generating insights
Time to go in depth into one or more topics and generate some insights! Generating insights means that we try to identify the root cause of problems that happened, or we try to find more detailed information about the topic that enables us to define some improvement actions or things we can change.
After the gathering data stage, there will most likely be more topics on the board than there is time to discuss. To quickly select the most important topics, you can let the team members do a dot voting. Everybody gets a certain amount of votes (mostly 3) that they can put on one or more items they would like to discuss with the team. After everybody used their votes, the item with the most votes is discussed first.
As the facilitator, you want to make sure you don’t jump into the discussion and start looking for solution at this point. You should support the discussion of the team by guiding them and asking the right questions to help them generate insights.
Decide what to do
Finally, you want to identify some actions items or changes that you can to do improve the items that have been discussed. Try to start small, and come up with a small change that you can implement in the next sprint. Coming up with 10 big changes that need months of time to implement are not very useful at this point. By starting small and only selecting one or two improvements that can already be implemented in the next sprint, you already create change which motivates the team.
A good action item is SMART:
- Specific: is the action item concrete, or is it vague / ambiguous?
- Measurable: is it clear when the action is completed? Do we know when the goal is reached?
- Attainable: is the action acceptable within the team(s) and organization?
- Relevant: is the action relevant to the team? Do they really want it, will it help the team?
- Timely: when (in time) do we plan to complete the action?
Retrospective of the retrospective
Last but not least, it’s nice to do a quick “retrospective of the retrospective”. Asking feedback from the team on the retrospective (format) allows you to continuously improve your retrospective as well.
There are formats to do this, but you can also just have each person sharing a few words on how they experienced the retrospective: are they satisfied with the format, with the results (action items) and with the way the retrospective went? What can be improved next time?
Doing a quick reflection on the retrospective also gives the team the opportunity to share their feedback and help the facilitator improve the sessions each time.
What most teams forget: reviewing the action items
A crucial step in the sprint retrospective is to review the action items from the previous retrospective. I often see teams forget this step because it is not prescribed in standard Scrum. You should always look back at the action items from the previous retrospective(s) and review the current status: is the action completed? If not, how comes? Do we need help, is the team not able to complete the action? Did we get new insights… and so on.
Not reviewing the action items may give the team the feeling that they don’t follow up on their actions, which leads to the team taking less ownership of the action items in the future.
We usually do this at the end of each retrospective when we summarize the action items of the current session.
Sprint Retrospective Formats
At Scrumbeginner, we provide a toolbox with retrospective formats which can give you inspiration for your retrospectives. Some of these formats are made by us, all formats are free to use.
You can find the toolbox here or via the link at the bottom of this post.
Tips & Tricks
- Don’t try to solve everything in one retrospective or sprint. Start small, do one or two improvements per sprint and enjoy the success of continuous improvement.
- Switch up your retrospective formats. Using the same format every retrospective may become boring after a while, and prevent the team from having inspiration.
- As a Scrum Master, focus on facilitation the discussion(s) during the retrospective. It is not your responsibility to find the solution and define the action items, you should enable the team to do this instead. This is easier said than done, because it’s in the human nature to solve problems.
Recent comments