The Scrum Sprint Retrospective — Stage 7 - dummies

The Scrum Sprint Retrospective — Stage 7

By Mark C. Layton

The seventh and final stage in the roadmap to value is the sprint retrospective. This is yet another scrum event that takes place after every single sprint.

The sprint retrospective, the seventh and final stage in the roadmap to value.
The sprint retrospective, the seventh and final stage in the roadmap to value.

The purpose of the sprint retrospective is to provide an opportunity for the scrum team — scrum master, product owner, and development team — to assess what went well in the sprint that just finished, and what can be improved. It’s inspect and adapt one more time, with a focus on the people, processes, and tools that the scrum team is using.

The outcome of the retrospective should be plans of action to continuously improve at scrum, people, processes, and tools every sprint. While the scrum framework is simple (three roles, three artifacts, and five events) and doesn’t require tweaking, each individual scrum team will have its quirks and nuances because of the nature of such aspects as their product, organization, and development methods. Through the process of inspect and adapt, you’re able to hone those individualities so that they’re aimed toward the project goals.

Because the sprint retrospective asks for input and feedback from all scrum team members, it also increases ownership through engagement and a sense of purpose. The team spirit is enhanced. This in turn leads to an increase in productivity and velocity. This is self-management.

It’s critical in sprint retrospectives to create a trusting environment. Each person’s view is listened to and respected, and nothing is taken personally. Trust is the key to the retrospective not being a labyrinth of euphemism or politics. The scrum master has a pivotal role in creating the environment of trust.

The sprint retrospective may unveil problems within the team. This is where an adept scrum master can facilitate the event such that these issues are dealt with in an equitable and low-intensity environment. This is not a time for venting. It’s a time for actionable plans for improvement.

The sprint retrospective process

The sprint retrospective takes place at the end of every sprint, after the sprint review and before the next sprint’s planning session. It’s often done as last thing on the last Friday of the sprint. For each week of sprint, 45 minutes is timeboxed for this event.

The entire scrum team participates, and at the team’s discretion, other people may be invited (like customers and stakeholders) if the team believes that they may have valuable insights to needed improvements for the scrum team.

In preparation for the retrospective, everyone should consider how the sprint went and jot down any ideas or concerns. As always, use simple tools like sticky notes — avoid formalities and presentations. The idea is to recognize internal, team inefficiencies and rectify them.

While the scrum master facilitates the meeting, everyone participates at a peer-to-peer level. The purpose of the sprint retrospective is to inspect the sprint that just ended to

  • Identify what went well in the sprint, with regard to such interactions as processes, tools, and team dynamics

  • Discuss and discover opportunities for improvement

  • Define an action plan for implementing the improvement(s)

In the retrospective, remember to emphasize and give equal airtime to what went well. Don’t gloss over it quickly. It’s important to focus on the positive and to identify what’s working well so that you keep doing it! Rejoice as a team in your successes! Especially during initial scrum implementation, it’s important to recognize the wins, big and small. An effective way of keeping things positive and avoid isolating people during a retrospective is the sandwich technique. Start with positive, work through the negative, and then end with more positive.

Key to the retrospective discussion is that it’s action oriented and not focused on justifying. When discussing what went wrong and you hear the word because, it’s a good indication that the discussion is heading down the path of justifying why someone did something a certain way, and then begins the finger-pointing and defensiveness. You want to keep moving forward with issues and actions. Don’t get bogged down in.

To maximize retrospective effectiveness, use the process outlined by Esther Derby and Diana Larsen in Agile Team Retrospectives: Making Good Teams Great (published by Pragmatic Bookshelf):

  1. Set the stage.

  2. Gather data.

  3. Generate insights.

  4. Decide what to do.

  5. Close the retrospective.

Each aspect of the retrospective can be facilitated by a number of activities that are engaging and provoke individual thought and group discussion. Examples include Triple Nickels, Five Whys, SMART Goals, Temperature Reading, Team Radar, and Mad Sad Glad.

To stimulate discussion in retrospectives, frame any of these activities around specific contexts, such as

  • What is keeping you from increasing your velocity from 36 to 38?

  • Does everyone have the tools that they need to do the job?

  • Do any impediments keep repeating?

  • Is your daily scrum effective at identifying impediments and coordinating daily priorities?

  • Is your team lacking certain skills, and how can you resolve them?

Some scrum teams will need to be coaxed and prodded to get engaged. They may be hesitant at first to say what they truly feel. Others will be the opposite. They may all want to talk at once and be bursting with ideas and input. This is where a perceptive and proactive scrum master (facilitator) adapts to work with either type of group, or anything in between, to achieve the best results.

The results from the retrospective should be put into the product backlog as “improvement” items. It should be a scrum team agreement that at least one goes into every sprint. Bring at least one priority retrospective item into the next sprint — it might be from the latest retrospective or a previous one. After all, why wait? The purpose is to inspect and adapt, so don’t delay the adapt part!