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.

The sprint retrospective is a time set aside at the end of every sprint for the Scrum team
to inspect and adapt its process and implementation of Scrum.
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.