The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works.
Empiricism
Like all Scrum’s events, the Retrospective is a mechanism of empiricism – inspecting the way the team works, collaborates and delivers its outcomes. The outcome of the Retrospective are actionable items that are added to the Sprint Backlog for the upcoming Sprint.
Who attends?
- The Product Owner (they’re part of the Scrum Team).
- The Agile Team (also known as the Development Team).
- The Scrum Master.
Managers, stakeholders, and other parties don’t attend the Retrospective. Sometimes Retrospectives require a safe place to discuss failures or have difficult conversation about what’s not working within the team and why.
What does the Retrospective involve?
The whole Scrum Team:
- Examines data from the Sprint. This could include velocity trends, the quality of its work, cycle time, assessing whether estimations were accurate, team morale, customer satisfaction, or action plans for improvements from the previous Retrospective.
- Discusses behaviours that impacted the Sprint – both positive and negative.
- Generates insights into what happened during the Sprint, what the metrics really mean, and why.
- Identifies tangible 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.
The Scrum Master:
- Encourages openness, courage to have honest conversations, and to make improvements and opportunities for learnings transparent.
- Helps the Scrum Team to ensure that items from the Retrospective are actionable by the team themselves.
- Helps guide the conversation to encompass the whole Scrum Team, including the Product Owner, not just what individuals might do to improve delivery of the Increment.
Actions from the Retrospective aren’t “let’s do a workshop next Sprint to make a decision or plan”. The Retrospective is that workshop.
Scrum Masters may also have to remind participants that removing Scrum events is not within their power to decide “not to do”. If an event isn’t proving of value to the Scrum Team, discussion should encompass “what can we all do to improve its value”, not “let’s just not do it anymore”.
