At the end of each Sprint, the Scrum Team meets for the Sprint Retrospective. The purpose is to review how things went with respect to the process, the relationships among people, and the tools. The team identifies what went well and not so well, and identifies potential improvements.
The Sprint Retrospective is one of the most important and least appreciated practices in the Scrum framework. It is important because it gives teams the chance to customize Scrum to their unique circumstances. It is under-appreciated because some people have a misguided view that it takes time away from doing “real” design, build, and test work.
The Sprint Retrospective is a crucial contributor to the continuous improvement that Scrum offers. Scrum teams hold Retrospectives each and every sprint, allowing teams to take advantage of insights and data before they are lost. Because a Scrum Team meets at the end of each Sprint to inspect and adapt its Scrum process, it can apply early and incremental learning throughout the development process and thereby significantly affect the outcome of the project.
Because the Sprint Retrospective is a time to reflect on the process, we need the full Scrum Team to attend. This includes all members of the Development Team, the Scrum Master, and the Product Owner. Collectively, these team members have a rich and diverse set of perspectives that are essential for identifying process improvements from multiple points of view.
The Scrum Master attends, both because he is an integral part of the process and also because he is the process authority for the Scrum Team. Being an authority doesn’t mean that the Scrum Master should tell the team how to change its process. Instead, it means that he can point out where the team is not adhering to its own agreed-upon process and also be a valuable source of knowledge and ideas for the team.
Some argue that having the Product Owner at the Retrospective might inhibit the team from being completely honest or revealing difficult issues. While this can be a risk in some organizations, the Product Owner is a critical part of the Scrum process and as such should be part of discussions about that process. If there is a lack of trust between the Product Owner and the Development Team, or there is a low level of safety so that speaking candidly isn’t comfortable, perhaps the Product Owner should not attend until the Scrum Master can help coach those involved toward creating a safer, more trusting environment.
Each Sprint Retrospective should have a well-defined focus. The default focus is to review all relevant aspects of the process the Scrum Team used during the current Sprint. Establishing and communicating the focus before the start of the Retrospective allow the Scrum Team to determine if any non-Scrum team members should be invited. In addition, knowing the focus before the start of the Retrospective allows the team to select appropriate retrospective exercises and gives people time to gather and prepare any data needed to ensure a smooth performance of the retrospective.
Once we have established the focus and final participants for the upcoming Retrospective, we can determine which exercises might help participants to engage, think, explore, and decide together. A typical Retrospective includes exercises like ‘brainstorm insights‘ and ‘group and vote on insights‘. However, we might choose to vary these exercises to support a particular focus or set of participants. A website that provides a number of exercises to plan Retrospectives is http://www.plans-for-retrospectives.com. Another website with lots of useful games for Retrospectives and other games to do with your team is http://tastycupcakes.org.
Like Sprint Reviews, Retrospectives happen at the end of each Sprint, often immediately following the Sprint Review, and generally should recur at the same place, day, and time each Sprint. The exact length of the Retrospective is influenced by factors such as how many people are on the team, how new the team is, whether any team members are located remotely, and so on. All Scrum meetings are time boxed. The recommended time box for the Sprint Retrospective is one hour per week of Sprint duration.
Inputs to the Sprint Retrospective include the agreed-upon focus for the retrospective and any exercises and materials that the team might decide to use during the Retrospective. One piece of input every attendee will bring without fail is his own subjective data regarding the current Sprint. Another Retrospective input is a backlog of insights produced in previous Retrospectives.
The outputs of the Sprint Retrospective include a set of concrete improvement actions that the team has agreed to perform in the next Sprint. The outputs might also include a backlog of insights collected during the current Retrospective that the team will not address in the upcoming Sprint but might choose to address in the future. Team members should also expect improved camaraderie as an output from a retrospective.
While many retrospective approaches exist, most seek to answer the following questions:
- 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?
Frequently participants are asked to brainstorm insights and then capture them on cards and place them on a shared wall or other surface so that everyone can see them. Another source for insights might be the team’s insight backlog, a prioritized list of previously generated insights that have not yet been acted upon. Once the cards have been placed on the wall, the participants will need to organize them. After creating a shared context and mining the data for insights, the participants should have identified many areas for improvement in their use of Scrum and, by extension, the way they work together to deliver value.
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 Scrum Master might own but someone else in the organization has to resolve.
Once the final improvement actions have been determined, the participants close out the Retrospective. Many close by recapping what actions the team has decided to take based on what the participants learned. Closing is also a good time to appreciate people and their participation. Each participant should say a few kind words of appreciation regarding the contributions made by others.
After closing the retrospective, it is critical that the participants follow up and carry out the improvement actions so that the team is more effective during the next Sprint. It is also important to keep a watchful eye out for issues that might prevent the retrospective from being successful and to quickly act on them.