Sprint Retrospective

The Sprint Retrospective is the last ceremony in the Sprint. The Sprint Retrospective takes place after the Sprint Review and before the next Sprint Planning. The meeting should be time-boxed to no more than an hour per week of Sprint length. The Scrum Master facilitates the meeting, keeping it on track, focused, and within the timebox.

This is the time when the members of the Team have the opportunity to inspect and adapt their process. The Team members sit down and talk about what went right, what could have gone better, and what can be made better in the next Sprint. The goal is to discover the improvement, or Kaizen, in their own process that they, as a Team, can implement right away.

If the team is able to consistently have strong retrospectives, and they produce relevant process improvement that build sprint to sprint, it will continuously improve.

To be effective, this meeting requires a certain amount of emotional maturity and an atmosphere of trust. It is crucial that the Team take responsibility for its outcomes as a Team, and not as individuals. The key thing to remember is that the team is not seeking someone to blame but rather looking at the process. The Team should ask questions like: Why did that happen that way? Why did we miss that? What could make us faster? The idea here is to examine people and relationships as well as process and tools. People have to have the fortitude to bring up the issues that are really bothering them in a way that is solution oriented rather than accusatory. And the rest of the team has to have the maturity to hear the feedback, take it in, and look for a solution rather than getting defensive.

By the end of the meeting the Team and the Scrum Master should agree on one process improvement that they will implement in the next Sprint. That process improvement, sometimes called the kaizen, should be put into the next Sprint’s Backlog, with acceptance tests. At the next Sprint Review the issue is revisited to see what difference, if any, the process change has made. If Team performance improved, the change should be kept. If performance did not, the Team needs to develop another hypothesis on what the root cause may be. It’s important to just choose one change. If the Team tries to implement multiple changes, it will be difficult to figure out which process change solved the real issue and led to increased performance.

There are many different ways to run Retrospectives. Scrum Inc. recommends using the Happiness Metric.

However, there are other ways to approach it.

One way, illustrated in the slides, is to structure the Retrospective is to draw four columns on a whiteboard, labeled:

• What went well?

• What could have been better?

• Things to try?

• Issues to escalate?

Each member of the Team adds items to the lists. By putting a check mark next to repeated items a consensus starts to emerge. The Team then discusses what it thinks are the underlying causes and agrees on the single most important improvement (the kaizen) to try in the next Sprint. As Jeff points out in the video, in the next Sprint Review the issue should be revisited to ensure that progress has been made toward completing the Definition of Done for the identified improvement.

There are a whole bunch of other methods actively discussed at retrospectivewiki.org. A great resource for people who want to delve deeper into the topic is Esther Derby’s Agile Retrospectives: Making Good Teams Great

 

Patterns: 

Sprint Retrospective

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Next Suggested Topic: Potentially Shippable Product

Back to the Framework 


Add Comment Register



Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>