The Scrum Guide – 2020
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
© 2020 Ken Schwaber and Jeff Sutherland
Commentary
Depending on the personality of the team members these meetings can be challenging for the Scrum Master. Some teams are quite communicative, especially about the nuisances they have faced during a sprint. An eruption of low-importance complaints may deliver an important message but may also just overshadow the real issues to talk about. Others may simply state that it was all good, there is nothing to talk about. It is difficult to make people talk when they do not feel like talking, indifference is hard to overcome.
However, it is often easy to point out what did not go well from an efficiency point of view. E.g. the team delivered less than half of the forecasted items, stakeholders articulated critics during the review, etc. The goal is not to blame the team but to help them improve. That is to say, find the path that leads to better delivery performance. Once we admit what went wrong, we start recognizing what really went well and how can we fix the pain points.
It is just as important to acknowledge performance and celebrate success. Teams often forget that motivation comes from positive interactions and positive outcomes. The more rewarding our work is, the better we can do it.
Format of the Sprint Retrospective
A detailed article demonstrating the classic format is available from Atlassian: How to Run an Agile Retrospective Meeting with Examples. It describes in detail the three topics mentioned in the Guide: “The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.” It is very straightforward, this is the original Agile concept of a retro, but it is not always efficient and can be quite boring.
The Scrum Guide describes the desirable outcome, but it does not prescribe practices anymore. For alternatives, let’s check out this great collection from Easy Retro 100+ Sprint Retrospectives Ideas.
Is Sprint Retrospective important?
Scrum experts – for example Jeff Sutherland – emphasize the importance of the retrospective. The retro’ is the best occasion to improve a team’s efficiency.
Many teams feel Retrospective is a waste of time. However, ‘retro’ is the best occasion to address generic impediments. There is no better time to work on the efficiency of the team. What is more, the Guide suggests the problems should be addressed ASAP and even added to the Sprint Backlog. The 2017 version specifically described that every Sprint Backlog should have at least 1 item that improves the process, not the product.
Considering the conflict between the importance of the Retrospective and the difficulty of having a good Retrospective, it is essential that the Scrum Master learn efficient facilitation techniques designed for this event.
Key Takeaways
- The Retrospective is an opportunity to inspect the process and adapt the modus operandi.
- Mind the timebox: maximum of 3 hours for a one-month Sprint, for shorter Sprints the event is also shorter and does not depend on team size.
- The self-managing Scrum Team is supposed to work on the identified problems ‘as soon as possible’, thus no strict rules are prescribed and there is no dependency on the management.
- Don’t forget the Scrum Values! Be open, focused and respectful.
External content: Scrum.org’s YouTube video on Sprint Retrospective facilitation
The Scrum Guide – 2017
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.
The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
©2017 Ken Schwaber and Jeff Sutherland.
The Scrum Guide – 2010
Sprint Retrospective
After the Sprint Review and prior to the next Sprint Planning meeting, the Scrum Team has a Sprint Retrospective meeting. This is a three hour, time-boxed meeting for monthly Sprints (allocate proportionately less of the total Sprint length to this meeting). At this meeting, the ScrumMaster encourages the Scrum Team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint. Many books document techniques that are helpful to use in Retrospectives.
The purpose of the Retrospective is to inspect how the last Sprint went in regards to people, relationships, process and tools. The inspection should identify and prioritize the major items that went well and those items that-if done differently-could make things even better. These include Scrum Team composition, meeting arrangements, tools, definition of “done,” methods of communication, and processes for turning Product Backlog items into something “done.” By the end of the Sprint Retrospective, the Scrum Team should have identified actionable improvement measures that it implements in the next Sprint. These changes become the adaptation to the empirical inspection.
© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved
“to ensure continuous improvement, it [the Sprint Backlog] includes at least one high priority process improvement identified in the previous Retrospective meeting“.
Is this “process improvement” considered a Product Backlog Item? Would it be listed on the Product Backlog or only on the Sprint Backlog?
This is quoted from the Sprint Backlog chapter. Process improvements would be added to the Sprint Backlog.
The Product Backlog should only contain items pertaining to the product. A process improvement (e.g. a new test automation solution) is not part of the product and it would be unfortunate to mingle the two.
Actually, there is even a trick question about it in the open assessment, which means real test questions may also address the same.