Exploring the Review and Retrospect Phase of a Scrum Project
A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK?). After the Implement phase comes the Review and Retrospect phase.
This phase includes three processes that focus on reviewing the deliverables and work that has been done and determining ways to improve the practices and methods used to do project work. It is important to note that the processes are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some processes, depending on the specific requirements of each project.
Convene Scrum of Scrums
This meeting is usually facilitated by the Chief Scrum Master and is intended to focus on areas of coordination and integration between multiple Scrum Teams. Though not held as often, the Scrum of Scrum (SoS) operates similar to the Daily Standup meeting during the Implement phase. In the Review and Retrospect phase, Scrum Team representatives convene SoS Meetings at predetermined intervals—or whenever required—to demonstrate deliverables created by two or more teams working in unison and to collaborate and share lessons learned from individual team Retrospect Sprint meetings. This is especially important when there are tasks involving inter-team dependencies. These meetings give teams the opportunity to showcase their achievements and provide feedback to other teams. SoS Meetings also serve as a forum where Scrum Team members may transparently discuss issues impacting their project. Timely discussion and resolution of issues greatly improves coordination between different Scrum Teams and also reduces the need for redesign and rework.
*Please note that the Convene Scrum of Scrums process is relevant only for large projects where multiple Scrum Teams are involved.
Demonstrate and Validate Sprint
In this process, the Scrum Team demonstrates the Sprint deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance from the Product Owner. Accepted Deliverables may be released to the customer if so desired. A list of Accepted Deliverables is maintained and updated after each Sprint Review Meeting. Deliverables that do not meet the Acceptance Criteria are called Rejected Deliverables. User Stories associated with Rejected Deliverables get added to the Prioritized Product Backlog so they can be considered as part of a subsequent Sprint to rectify any issues. This is highly undesirable because the objective of every Sprint is for the deliverables to meet the criteria for acceptance.
Retrospect Sprint
In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned, which can be applied to future Sprints. As a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations. Agreed Actionable Improvements are the primary output of this process. They are the list of actionable items that the team has created to address problems and improve processes in order to enhance their performance in future Sprints. Once the Agreed Actionable Improvements have been elaborated and refined, the Scrum Team may consider action items to implement the improvements. The Retrospect Sprint Log is a record of the opinions, discussions and actionable items raised in a Retrospect Sprint Meeting. The Scrum Master could facilitate creation of this log with inputs from Scrum Core Team members. The collection of all Retrospective Sprint Logs becomes the project diary and details project successes, issues, problems and resolutions. The logs are public documents available to anyone in the organization.
Following the three processes of the Review and Retrospect phase helps those involved in a Scrum project to review deliverables and identify impediments to neutralize in the future. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Review and Retrospect phase, however, it is imperative to analyze the project and determine what worked and what didn’t work.