Conduct Release Retrospective
Similar to a Sprint Retrospective, a Release Retrospective is an opportunity to grow and improve. By reflecting on the Release just launched, you are able to gain wisdom and perspectives that help you to codify what you have learned and avoid similar issues in the future.
A Release Retrospective is the practice of reviewing the processes within all the release’s Sprints and discussing what went well, what did not go well, and what process improvements can and should be implemented as the next release is being planned.
Don’t make the same mistakes twice. When you understand the root cause of an issue, you can create a strategy to avoid it in the future. Teams are able to share lessons learned in this open, honest, blame-free environment so that past problems are turned into opportunities for growth and greater efficiency.
The entire Scrum should participate in this retrospective, and it should be facilitated by the Scrum Master. In some cases, other key stakeholders may be invited to participate. You’ll start by reviewing the release goals, timeline, budget, major events, and success metrics. Then you’ll discuss what worked well and what didn’t. Most importantly, you’ll identify specific ways to improve future work. Over the two to three hours, you should develop strategies that everyone can agree on for future project implementations.
The Scrum Master must set the expectation that the retrospective is “blameless”- meaning that this meeting is about sharing insights and learning and not about scapegoating, venting, or working out interpersonal issues. This is an important guiding principle to enable open and honest feedback during the retrospective.
Use the same format as for Sprint retrospective (ie: What Went Well, What would you do differently next time), just with different categories appropriate to the specific release.
Published May 8, 2018 — Updated May 25, 2018