Chapter 22: Sprint Retrospective

Scrum provides two inspect-and-adapt opportunities at the end of each sprint: the sprint review and the sprint retrospective. In the previous chapter I discussed the sprint review, where the team and stakeholders inspect the product itself. Let’s now turn our attention to the sprint retrospective, where the Scrum team examines the process used to build that product.

I begin with an overview of the purpose of and participants in the sprint retrospective. I then describe the prework and major activities associated with a sprint retrospective, the most important of which occur after the sprint retrospective when the participants actually follow through on the improvements they identify.

Sprint Retrospectove Overview

Sprint retrospectives give the whole Scrum team an opportunity to stop for a moment and examine what's happening, analyze the way they work, identify ways to improve, and make plans to implement these improvements. Anything that affects how the team creates the product is open to scrutiny and discussion. Retrospectives are crucial because they give Scrum teams the chance to customize Scrum to their unique circumstances.

Sprint Retrospective Timing

The sprint retrospective typically is the last activity of the sprint. It should generally recur at the same weekday, time, and place each sprint.

All retrospectives should be timeboxed; in most cases, a sprint retrospective should take between one hour and three hours, depending on sprint length. Do not spend less than one hour or more than four.

Sprint Retrospective Participants

The entire Scrum team (development team, ScrumMaster, and product owner) should attend the sprint retrospective. The development team includes everyone who is designing, building and testing the product. Collectively, the Scrum team members have the diverse perspectives necessary to reflect on the progress and suggest improvements.

On certain occasions, the Scrum team might also decide to invite people from outside the Scrum team if their insights or perspectives will contribute to team learning during the retrospective.

Sprint Retrospective Prework

Not all sprint retrospectives require prework. For short-duration sprints or for teams who are using a well-practiced format, little if any prework is required.

Define Retrospective Focus

The default retrospective focus is to review all relevant aspects of the process used during the previous sprint. However, sometimes teams want to alter the focus for a particular retrospective depending on what is important to the team and where improvements are needed. Some teams might want to focus on ways they can improve technical skills; others might want to problem solve ways to build features that better match customer expectations.

Establishing and communicating the focus of the retrospective ahead of time allows the team to determine if any non-Scrum members should be invited. It also allows the team to select appropriate retrospective exercises and gather any necessary data.

Select Exercises

Teams also need to choose exercises that will help them engage, think, explore, and make decisions. Some common exercises are to create and mine a sprint event timeline, brainstorming, and grouping and voting.

During prework, teams don't have to decide exactly which exercises they will use—they need only do enough research to have some exercise choices and materials and data available to support any of the potential exercises.

Gather Objective Data

Any legwork needed to collect data should happen before the retrospective. Objective data is hard data (not opinions), such as what events happend and when, counts of the number of PBIs that were started and not finished, or the feature burnup for the sprint. At this time, the data only needs to be collected, not analyzed.

Structure the Retrospective

Because retrospectives can vary in length, place, participants, and time, it's a good idea to review the desired structure as part of the retrospective prework. The exact length will depend on how many people are on the team, how new the team is, whether any team members are located remotely and so on. The location will vary as well. Some teams like to hold their retrospectives in the same area where their big visible charts are located. Others prefer to leave the standard team area. In many cases, the ScrumMaster can facilitate the meeting; but at times, you might want to bring in an outside facilitator, either someone from outside the team or even outside the company. All of these decisions need to be made and communicated during prework.

Sprint Retrospective Approach

The tangible prework items (focus, exercices, and objective data) are inputs to the retrospective. Other inputs include subjective data and the insight backlog. Outputs include a list of improvement actions, the updated insight backlog, and improved camaraderie.

The team's approach to a sprint retrospective can be as simple as Scrum team members coming together to discuss questions such as

• What worked well this sprint that we want to continue doing?
• What didn't work well this sprint that we should stop doing?
• What should we start doing or improve?

An approach that I find useful (similar to one described by Derby and Lawson in their 2006 book Agile Retrospectives) is to set the atmosphere for the retrospective, create as shared context among the participants, identify insights that can lead to improvements, determine concrete improvement actions to take during the next sprint, and close the retrospective. Let's delve more deeply into each of those steps.

Set the Atmosphere

Establish the atmosphere that makes people feel comfortable and safe. Find simple ways to get them talking.

Create Shared Context

A group of people can experience the same event and yet interpret it quite differently. To create a shared context among a team, first ground the retrospective by sharing objective data about the sprint. Then invite people to share subjective data—what were some things they observed during the sprint and/or how did they feel about the sprint? Some exercises that are helpful for creating a shared context include an event timeline and an emotions seismogram.

Identify Insights

The participants next identify insights by collaboratively examining, interpreting, and understanding both the objective and subjective data. Doing this effectively requires a system-level focus, which helps teams find the root cause of issues.

Brainstorming is an excellent activity for capturing insights. Another source might be the team's insight backlog, a list of previously generated insights that have not yet been acted upon. The insight backlog is typically updated at the end of each sprint to reflect new insights.

Determine Actions

Once the team has identified their insights, they need to move from discussing them to taking demonstrable actions to leverage them.

Often, the team identifies more insights than it can address during any one sprint. When this happens, the team will need to prioritize the insights, perhaps through dot voting or some other prioritization activity. The team members will also need to determine how much capacity they will have for any improvement actions during the upcoming sprint.

Once the team has prioritized its insights and estimated its capacity, the team can define concrete, actionable steps to leverage the insights and improve the Scrum process. Most actions will take the form of specific tasks that one or more Scrum team members will perform during the upcoming sprint. Sometimes the actions represent impediments that the ScrumMaster might own but someone outside the Scrum team must resolve. Sometimes, teams discover that it isn't possible to immediately address the insight and have to choose instead to explore the insight. All of these actions can be tracked in the insight backlog.

Close the Retrospective

The last step is to close out the retrospective. Many do this by recapping the actions the team has decided to take based on what the participants learn. It is also a good time to appreciate people and their participation. I also recommend asking the team for suggestions to improve future retrospectives. A retrospective is, after all, part of the Scrum framework and as such should also be subject to inspection and adaptation.

Follow Through

To ensure that what happens in the sprint retrospective does not just stay in the sprint retrospective, the participants should follow up on the actions they choose to complete. Frequently the easiest way to handle the improvement actions is to populate the sprint backlog with tasks corresponding to each action prior to bringing in new features. The teams available capacity to work on new features would then be adjusted downward by the estimated time these improvement tasks will take.

I do not recommend keeping a separate improvement backlog. It will always lead to the improvement actions taking second place to the work of the sprint. Any actions that do not require team time will likely find a home on the ScrumMaster's impediment list. And actions that are designed for other teams or the organization as a whole can be placed into the appropriate backlog for the people who are expected to do the work. The ScrumMaster can follow-up on any of these outside-the-team improvements.

Closing

This chapter was focused on the sprint retrospective, the Scrum process feedback loop. The next—and last—chapter looks at the path forward.