After a project is over, it is important that the Scrum team and the stakeholders look back and discuss the lessons learnt during the course of the project. This in itself is a process, called the Retrospect project, which comes right after the deliverables are shipped.
The Release phase emphasizes delivering the Accepted Deliverables to the customer and identifying, documenting, and internalizing the lessons learned during the project. In the Retrospect Project process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.
Inputs
Scrum Core Team(s)
Chief Scrum Master
Chief Product Owner
Stakeholder(s)
Scrum Guidance Body Recommendations
In Retrospect Project process, Scrum Guidance Body Recommendations can include a repository of internal templates that support the future projects, and guidance for conducting the Retrospect Project Meeting. The guidance provided can relate to administrative procedures, audits, evaluations, and project transition criteria. Often, they also include how the organization will maintain the knowledge base of lessons learned and information from all projects.
Tools
Retrospect Project Meeting*
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.
Other Tools for Retrospect Project
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
Scrum Guidance Body Expertise
In Retrospect Project process, the primary responsibility of the Scrum Guidance Body is to ensure that the lessons learned in each project are not lost and are embedded in the organization. Also, there may be suggestions in the Scrum Guidance Body Recommendations concerning how the Retrospect Project meeting should be conducted.
Outputs
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 Program Product Backlog and 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.
Updated Scrum Guidance Body Recommendations
The self-organizing and empowered Scrum Team is expected to learn from any mistakes made during a Sprint – and these lessons learned help the teams improve their performance in future Sprints.. These lessons learned may also be documented in Scrum Governance Board Recommendations to be shared with other Scrum teams.
