If you search “agile retrospective,” you’re instantly bombarded with information on sprint retrospectives and little else. Even at EasyRetro, we’re a little guilty of placing all the focus on sprint retrospectives!
The retrospective format is a great way to evaluate your team’s performance to determine what went well and what can be improved. You can host a retrospective at any time, so it makes sense to have one at the very end of your project, right?
Release retrospectives are rarely performed, as they aren’t technically a part of Scrum. But maybe they should be!
What is a release retrospective?
Like a sprint retrospective, a release retrospective is a tool that helps to monitor and improve how a team is performing. The comprehensive retrospective offers a higher-level view of how the team works and is helpful for the team, stakeholders, and higher-ups.
As the name suggests, a release retrospective is performed at the very end of a release and before starting work on a new release. A release comprises many sprints and can include months or even a year’s worth of work.
Because there is so much work to assess, release retrospectives can take one or two days. Teams should have a well-arranged schedule going into the release retrospective, with all participants heading into the meeting with a complete understanding of the purpose of the retrospective so they can make the necessary preparations. Because release retrospectives are for higher-level analysis of how the team works, it should involve product managers, development managers, product owners, stakeholders, and any other senior-level staff involved in the release.
Release retrospective vs. sprint retrospective: what’s the difference?
While the core goal of a release retrospective is the same as a sprint retrospective — identifying what went well and what needs improvement — the two events are more different than you may expect.
Unlike the almost laid-back, flexible approach used during sprint retrospectives, a release retrospective should be a structured and organized event. This will involve a certain amount of preparation, including agendas, schedules, and gathering relevant data.
Sprint retrospectives are designed to include the development team and focus on minor adjustments to improve processes. Release retrospectives have a broader scope and include senior management and stakeholders, essentially acting as an executive overview of the entire project.
Release retrospectives rely on anonymous data collection and voting. This allows the participants to objectively view the project’s processes, people, and product aspects.
7 tips for release retrospectives
With such a focus on sprint retrospectives, you may be tempted to try and approach a release retrospective in the same way. But because the two retrospective formats are significantly different, they require different approaches.
When preparing your release retrospective, keep these tips in mind to ensure you get the maximum value from the exercise.
Chose a suitable location
Release retrospectives can be a long ordeal. They consider the entire project, which could mean looking through and analyzing months of data. With that in mind, it’s important to consider where you’re going to host the retrospective.
Make sure to pick an ample workspace that allows the participants plenty of breathing space and offers comfortable seating. You will also need audio-visual equipment and a whiteboard for presentations or post-it notes.
Recognize your team’s achievements
We all know how drained you can feel at the end of a long project, so why not use a release retrospective as an opportunity to acknowledge your development team?
The team will have built up a pretty substantial EasyKudos Board throughout the project. Open up the retrospective by looking through each kudos card and discussing the team’s achievements. This will boost morale, bring your team closer together, and give the higher-ups an insight into the team.
Identify key participants
A release retrospective should be a high-level event that includes senior management, stakeholders, product owners, and in some cases, customers.
Unlike sprint retrospectives, release retrospectives don’t need to involve the entire development team. However, you should include individuals who were integral to the project. They can help provide context to the discussion and clarify why the development team made certain decisions.
Gather meaningful data
Release retrospectives require a fair amount of preparation. After all, the retrospective results could uncover critical changes to make going forward and change how the business or team works.
Participants should gather key data such as timelines, key feedback from sprint retrospectives, and scope before the retrospective. If any features were removed or added during development, you should also record the reasons for those decisions.
Plan your session to match the project timeline
This may seem obvious, but your release retrospective plan should reflect the project’s timeline. This ensures that every aspect of the project is analyzed. It also allows the participants who were not directly involved in development a chance to experience how the release came together.
Great management involves taking into account how your team feels, not just how they work.
By building an emotional seismograph, you can see how your team felt during each stage of development. As you build the graph, the team’s representatives can explain what was happening and how they were feeling at each stage.
Discuss what’s next
The final stages of a release retrospective should naturally focus on what’s next. Find out what the team would do differently, discuss ways to improve, and ask the group what advice they would give to themselves if they started the project again.
By the end of the release retrospective, everyone should clearly understand how the release came together and how the team will approach the next project.