The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
If the daily standup is one of the most iconic rituals of scrum, the sprint retrospective may be the most representative of the agile philosophy. Sprint retrospectives offer the team the opportunity to reflect on what they’ve been doing at the end of every sprint, and figure out how they want to modify their process going forward.
Objective
A sprint retrospective gathers the team together to consider how the sprint that was just completed went for everybody. During the ritual, everyone in the room will be asked what went well, what didn’t go well, and what commitment they’re willing to make as a group to improve things in the next sprint. The goal is to come away with a set of modifications to the process that everybody on the team agrees to try for the upcoming sprint.
All the members of the development team, the scrum master, and the product owner are expected to participate in a sprint retrospective. The ritual is led by the scrum master.
Note: Guests are Rare at Retrospectives
Rarely are guests invited to attend the sprint retrospective. This is in order to encourage people to open up about what might have gone wrong during the sprint, and to be candid about how they felt and what issues came up for them. This meeting can be emotional, and the intimacy of a private team environment provides a more supportive context.
Time Box
Teams may find that the amount of time they spend in the retrospective mirrors the amount of time they might spend in the sprint demo. For a two-week sprint, it’s not unusual for the team to devote half a day to the retrospective. When scheduling the retrospective, it’s good to err on the side of generosity with the time, to avoid cutting off access to valuable insights from team members.
The amount of time a team dedicates to the sprint retrospective reflects the importance they give to paying attention to their own process, and improving as they go. Some teams may try to limit the amount of time spent in the retrospective. This can come at the expense of communication and improvement. One of the most important aspects of scrum is its emphasis on discussion as a means of enhancing the product development process.
Preparation
Sprint retrospectives can be highly charged. Everybody involved in the scrum should come to the ritual with some thought in mind about what might have happened during the sprint that they want to comment on. For some people, this can mean creating a long list of issues to raise.
The scrum master should come to the sprint retrospective with an agenda that makes sure both positive and negative feedback is gathered from all participants. It’s the responsibility of the scrum master to see to it that everybody has a voice and contributes to the process.
Warning: Make Sure the Retrospective Gets Proper Attention
The sprint retrospective is the one ritual that’s most frequently shortened, or even abandoned, by scrum teams. That can be a sign that the process in in trouble. Without adequate attention to the retrospective, the team is giving up the opportunity to improve their process. Often the people recommending that this ritual be given less time and attention are the people who are benefiting most from the status quo, at the expense of constant improvement. Making sure this ritual takes place and is given proper attention by everybody on the scrum team is a way of showing care and concern for everybody on the team.
What Went Well?
The scrum master should ask everybody in the room what they thought went well during the past sprint. This is usually done by going around the room and having everybody report about one or more things they thought went particularly well during the previous sprint. Unless this sprint was a total disaster, most people should be able to come up with something they thought went well[2].
Part of the value of getting people to discuss what went well is to bring people together and give them an opportunity to recognize and appreciate the good work they and their teammates were responsible for.
Warning: Hold Off on Discussion Until Everyone Has Raised Their Points
While everybody’s participation should be encouraged before the meeting is over, it’s not a good idea to allow people to respond, or discuss the points raised, until everyone has had a chance to share their list. The scrum master should provide an opportunity for more open discussion later, but it’s most important to give everybody in the team a chance to speak before this deeper discussion starts.
What Didn’t Go Well?
Next the scrum master should go around the room asking people to report what they didn’t think went so well during the sprint. This is a more delicate subject, because people may tend to bring up uncomfortable or unpleasant issues.
As before, everyone should be asked to participate. Bringing out honest responses from people about subjects they may feel uncomfortable discussing is part of the skill of a strong scrum master. If somebody really doesn’t want to speak, or has something to say that they don’t want to bring up in front of the group, they should be encouraged to talk about it independently with the scrum master outside of this ritual.
Saying negative things in front of teammates can feel uncomfortable. Part of the job of the scrum master is to help coach people from sprint to sprint in how to frame their issues so that they can be discussed in a productive way. This ritual isn’t about personal attacks, but about finding ways in which the team can work better together.
Note: Ordering This Ritual
The order of the sections of this ritual—dealing with what went well and what didn’t go well—may be reversed according to team preference. Scrum masters may also choose to follow any number of practices to get the team more engaged in this process, including games, note cards, advance submissions, etc. There’s a lot of room for creativity in planning this ritual.
What Should We Do about It?
After everybody has had an opportunity to discuss what they thought went well during the sprint, and what didn’t go so well, the floor should be opened for discussion. This is a chance for everybody on the team to say more about the issues they raised, as well as the issues raised by the other teammates, and what they think the team should be doing about them.
For things that went well, the team should try to find ways that the successes can be replicated in future sprints. They might have tried something new this past sprint that turned out to be successful, and that can be integrated into the process going forward.
For things that didn’t go so well, the team has the opportunity to discuss what went wrong. Sometimes the issue was that the process was not followed. Other times, the process actually got in the way, and needs to be adjusted. Everybody should be encouraged to give their opinions about changes that might be beneficial.
Eventually, the discussion will circle around to four or five key issues that the team wants to focus on. The scrum master should guide the discussion in such a way that these issues get phrased as revised practices—which the team can then agree to try for the upcoming sprint.
Note: Only Make Manageable Changes Between Sprints
While there may be many issues discussed, the team should agree on a small and manageable set of changes to make from one sprint to the next. As with user experience testing, the more changes you make between tests, the more difficult it is to isolate which ones were helpful, and which ones caused problems.
By the end of this ritual, the scrum master should present the team with a short and understandable list of changes to the process. Most importantly, the scrum master should poll the entire room, and make sure everybody is in agreement with this set of changes. Then the scrum master should record the team’s commitment to the revisions for the upcoming sprint. A team’s ability to reflect and improve is as important to its development as the commitment to a sprint backlog is to the product’s development.
Conclusion
In this chapter, we’ve gone over the four critical rituals for scrum: sprint planning, daily standup, sprint demo, and sprint retrospective. Each of these rituals is repeated once every sprint, except for the standup, which is performed every day.
These rituals take us from feature stories—written by a product owner—through team estimation, commitment to a sprint backlog, working through all of the stories, demonstrating that each story was completed and meets all of its acceptance criteria, to finally reflecting on what worked and what didn’t in the completed sprint, so that the team can constantly improve.
Next, we’re going to take a look at some of the artifacts of scrum. These tools help a scrum team to understand what they’re working on, track their progress, and work together effectively.
[2] One of the reasons this ritual takes as long as it does is because everybody’s participation is essential. Nobody should be left out.
Frequently Asked Questions (FAQs) about Sprint Retrospective
What is the main purpose of a Sprint Retrospective in Scrum?
The primary purpose of a Sprint Retrospective in Scrum is to provide an opportunity for the Scrum team to reflect on their work and identify opportunities for improvement. It’s a time for the team to discuss what worked well, what didn’t, and what changes could be made to improve the process and product. The retrospective is a crucial part of the Scrum framework as it promotes continuous learning and improvement.
How often should a Sprint Retrospective be conducted?
A Sprint Retrospective should be conducted at the end of every sprint, which typically lasts for two weeks. However, the frequency can vary depending on the length of the sprint. Regardless of the sprint duration, it’s important to hold a retrospective at the end of each one to ensure continuous improvement.
Who should participate in a Sprint Retrospective?
All members of the Scrum team should participate in the Sprint Retrospective. This includes the Scrum Master, the Product Owner, and the Development Team. Each member brings a unique perspective to the discussion, which can lead to more comprehensive and effective improvements.
How long should a Sprint Retrospective last?
The duration of a Sprint Retrospective can vary, but it typically lasts for about an hour for a two-week sprint. For longer sprints, the retrospective may last longer. The key is to ensure that there is enough time for all team members to share their thoughts and for the team to agree on action items for improvement.
What are some common formats for conducting a Sprint Retrospective?
There are several formats for conducting a Sprint Retrospective, and the choice often depends on the team’s preference. Some common formats include the “What Went Well, What Didn’t” format, the “Start, Stop, Continue” format, and the “Mad, Sad, Glad” format. Each format encourages team members to reflect on different aspects of the sprint and identify areas for improvement.
How can a team ensure that action items from the Sprint Retrospective are implemented?
To ensure that action items from the Sprint Retrospective are implemented, they should be clearly defined, assigned to specific team members, and tracked. The Scrum Master typically takes on the responsibility of tracking these action items and ensuring that they are addressed in the next sprint.
What role does the Scrum Master play in a Sprint Retrospective?
The Scrum Master plays a crucial role in a Sprint Retrospective. They facilitate the meeting, ensuring that all team members have an opportunity to speak and that the discussion remains productive and respectful. They also help the team to identify and agree on action items for improvement.
Can a Sprint Retrospective be skipped?
While it may be tempting to skip a Sprint Retrospective, especially when deadlines are tight, it’s not recommended. The retrospective is a crucial part of the Scrum framework that promotes continuous improvement. Skipping it can lead to missed opportunities for improvement and potential issues in future sprints.
How can a team make the most of a Sprint Retrospective?
To make the most of a Sprint Retrospective, the team should come prepared to discuss their experiences, be open to feedback, and be willing to make changes. It’s also important to create a safe and respectful environment where all team members feel comfortable sharing their thoughts.
What should be the outcome of a Sprint Retrospective?
The outcome of a Sprint Retrospective should be a list of agreed-upon action items for improvement. These action items should be clearly defined, assigned to specific team members, and tracked to ensure that they are implemented in the next sprint. The retrospective should also foster a sense of team unity and a commitment to continuous improvement.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
