15 RETROSPECTIVE
The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum framework and it is the final step in a Sprint. All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master. It is recommended, but not required for the Product Owner to attend. One Team member acts as the scribe and documents discussions and items for future action. It is essential to hold this meeting in an open and relaxed environment to encourage full participation by all Team members. Discussions in the Retrospect Sprint Meeting encompass both what went wrong and what went right. Primary objectives of the meeting are to identify three specific items:
- Things the Team needs to keep doing—best practices
- Things the Team needs to begin doing—process improvements
- Things the Team needs to stop doing—process problems and bottlenecks
These areas are discussed and a list of Agreed Actionable Improvements is created
15.1.1 Explorer—Shopper—Vacationer—Prisoner (ESVP)
This exercise can be conducted at the start of the Retrospect Sprint Meeting to understand the mindset of the participants and set the tone for the meeting. Attendees are asked to anonymously indicate which best represents how they feel regarding their participation in the meeting.
- Explorer—Wants to participate in and learn everything discussed in the retrospective
- Shopper—Wants to listen to everything and choose what he takes away from the retrospective
- Vacationer—Wants to relax and be a tourist in the retrospective
- Prisoner—Wants to be elsewhere and is attending the retrospective because it is required
The Scrum Master then collates the responses, prepares, and shares the information with the group.
15.1.2 Speed Boat
Speedboat is a technique that can be used to conduct the Retrospect Sprint Meeting. Team members play the role of the crew on a speedboat. The boat must reach an island, which is symbolic of the project vision. The attendees to record engines and anchors use sticky notes. Engines help them reach the island, while anchors hinder them from reaching the island. This exercise is Time-boxed to a few minutes. Once all items are documented, the information is collated, discussed, and prioritized by way of a voting process. Engines are recognized and mitigation actions are planned for the anchors, based on priority.
15.1.3 Metrics and Measuring Techniques
Various metrics can be used to measure and contrast the Team's performance in the current Sprint to their performance in previous Sprints. Some examples of these metrics include:
- Team velocity: Number of Story Points done in a given Sprint
- Done success rate: Percentage of Story Points that have been Done versus those Committed
- Estimation effectiveness: Number or percentage of deviations between estimated and actual time spent on Tasks and User Stories
- Review feedback ratings: Feedback can be solicited from Stakeholder(s) using quantitative or qualitative ratings, providing a measurement of Team performance
- Team morale ratings: Results from self-assessments of Team member morale
- Peer feedback: 360 degree feedback mechanisms can be used to solicit constructive criticism and insight into Team performance
- Progress to release or launch: Business value provided in each release, as well as value represented by the current progress towards a release. This contributes to the motivation of the Team and to the level of work satisfaction.
15.1.4 The outcome of the Retrospect Sprint Meeting
- Agreed Actionable: Improvements: Agreed Actionable Improvements are the primary output of the Retrospect Sprint process. They are the list of actionable items that the Team has come up with to address problems and improve processes in order to enhance their performance in future Sprints.
- Assigned Action Items and Due Dates: Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team. Each action item will have a defined due date for completion.
- Proposed Non-Functional Items for Prioritized Product Backlog: When the initial Prioritized Product Backlog is developed, it is based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review or Retrospect Sprint Meetings. These items should be added to the Prioritized Product Backlog as they are discovered. Some examples of non-functional requirements are response times, capacity limitations, and security related issues.
- Retrospect Sprint Log: The Retrospect Sprint Logs are records 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 Retrospect 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.
- Scrum Team Lessons Learned: The self-organizing and empowered Scrum Team is expected to learn from any mistakes made during a Sprint. These lessons learned help the Teams improve their performance in future Sprints. These lessons learned may also be documented in Scrum Guidance Body Recommendations to be shared with other Scrum Teams.
There may be several positive lessons learned as part of a Sprint. These positive lessons learned are a key part of the retrospective, and should be appropriately shared within the Team and with the Scrum Guidance Body, as the Teams work towards continuous self-improvement.
- Updated Scrum Guidance Body Recommendations: As a result of a Retrospect Sprint Meeting, suggestions may be made to revise or enhance the Scrum Guidance Body Recommendations. If the Guidance Body accepts these suggestions, these will be incorporated as updates to the Scrum Guidance Body documentation.
The Retrospect Project Meeting is a meeting to determine ways in which Team collaboration and effectiveness can be improved in future projects. Positives, negatives, and potential opportunities for improvement are also discussed. This meeting is not Time-boxed and may be conducted in person or in a virtual format. Attendees include the Project Team, Chief Scrum Master, Chief Product Owner, and Stakeholder(s). During the meeting, lessons learned are documented and participants look for opportunities to improve processes and address inefficiencies.
Some of the tools used in the Retrospect Sprint process can also be used in this process. Examples include:
- Explorer—Shopper—Vacationer—Prisoner (ESVP) exercise
- Speed Boat
- Metrics and Measuring Techniques
15.2.1 The outcome of the Retrospect Project Meeting
- Agreed Actionable Improvements: Agreed Actionable Improvements are the primary output of the Retrospect Project Review. They are the list of actionable items that the Team has come up with to address problems and improve processes in order to enhance their performance in future Sprints.
- Assigned Action Items and Due Dates: Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team or Stakeholders. Each action item will have a defined due date for completion
- Proposed Non-functional Items for Program Product Backlog and Prioritized Product Backlog: When the initial Program Product Backlog or Prioritized Product Backlog are developed, they are based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review, Retrospect Sprint or Retrospect Project Meetings. These items should be added to the Program Product Backlog (for the program) and Prioritized Product Backlog (for the project) as they are discovered. Some examples of non-functional requirements are response times, capacity limitations, and security related issues.
