Scrum Rituals: Sprint Retrospective
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.
