Release Retrospectives

For any organization that has projects that are of huge size, complex in nature, with huge numbers of resources located at various geographical locations, a lot of inter dependencies are present and a lot of coordination is required. As not taking up a big project is not an option, people who are involved in running these types of projects need to constantly review and monitor their progress and delivery. To do this monitoring effectively and to improve continuously for high-quality product delivery that satisfies the customers, different organizations adopt different mechanisms and methods at various stages in the life cycle of the projects. Holding release retrospectives is one such tool that has been effectively used by many organizations, with good results.


What is a release?

Before talking about release retrospectives, let us understand what a release is. A release would typically last three to six months, even a year, depending on the organization’s release cycle. A release comprises many sprints, and the timebox of each sprint could be two to four weeks.

What is the difference between a release retrospective and a normal retrospective?

A normal retrospective provides an opportunity to inspect and adapt the sprint cycle, to look back at how the sprint was and discuss as a team ways to make improvements in the coming sprints.

A release retrospective is an opportunity to inspect and adapt the release cycle rather than the sprint cycle. Of course, the inspection points would vary when it comes to the release. Although not part of Scrum, the basic idea of doing a release retrospective is to review and evaluate an entire release, which spans multiple sprints, for getting a higher-level picture by involving all the important stakeholders and higher management.

Who generally participates in the release retrospectives?

Generally, the senior management, aka the product managers, development managers, product owners, and all senior people involved in the release and strategic planning would participate. In some cases, the individual team ScrumMasters and a few representatives could join as well, based on the need.

What is the frequency of the release retrospective?

A release retrospective is held at the end of the release and usually before starting the next release cycle. A schedule is worked out well in advance, and the date and time are communicated to all concerned so that they come prepared with some data.

What could be the duration of a release retrospective?

Generally, a release retrospective may take one or two days, depending on the release length, format, and the agenda.

What could be discussed in the release retrospectives?

The focus of release retrospectives is to review how the release was with respect to strategic objectives, product quality, some common issues and patterns, what went well, what could be areas to improve, and so on.

Some of the common inspection points for a release retrospective could be:

  1. Product quality
  2. Current status of the projects
  3. Number of escaped defects
  4. Planned features versus delivered features
  5. Whether the features delivered were in order of priority
  6. The number of features developed that were really accepted
  7. The number of features delivered that are actually used by the customer
  8. The number of issues reported by the customer and the length of time we took to fix those issues
  9. Whether the release date was extended, and if so, why
  10. Whether we delivered all the scope planned for the release
  11. The number of defects getting generated on previous enhancements
  12. Whether we are taking interim customer feedback
  13. New technology initiatives
  14. Infrastructure issues causing release delays
  15. Performance improvement initiatives
  16. Any new tools to be introduced
  17. The optimization that can be done at various levels
  18. How we measured the data and any scope of improvement
  19. What strategies were highly effective

There could be many more.

The discussion for the release retrospective could be segregated into the following categories: technology, development, process, quality, etc.

There could be other inspection points and categories as well; these metrics are
mostly related to IT projects. Each product or project could have its own metrics, measurement criteria, and inspection points, depending on the nature of the

What could be some of the methods to gather data for a release retrospective?

Methods could include:

  1. Regular customer meet-ups; seniors could travel to the customer’s location to get their feedback.
  2. PO or senior management would have some regular checkpoints with customers to collect their feedback.
  3. We could conduct some customer surveys with predefined questions, based on the data points discussed in the section above.

What could be the preparation for a release retrospective?

Usually, since the working agreement of what needs to be discussed in the release retrospective is formulated well in advance, the concerned people have enough time to come prepared with project data. The prep time could be considerable, depending on the inspection points chosen for discussion in the release retrospective.

What could be the format of a release retrospective?

Generally, a release retrospective spans one or two days, depending on the size of the project, the agenda, and the number of teams involved.

In some organizations, the senior management and executive leadership participate, and the focus would be specific strategic objectives and goals.

Following could be the discussion points:

  1. Formulate the working agreement:
    • Discuss with all the attendees and make it clear that the objective of the release retrospective is to inspect and adapt.
    • Reiterate the prime directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills, their abilities, the resources available, and the situation at hand.
  2. The goal could be to discuss the release cycle timeline around the major buckets, such as like technology, development, quality, process, etc.
  3. For items that did not go well or for items that need improvement, brainstorming is done and some action plan could be formulated in terms of new initiatives at the organizational or group level. Some examples could be procuring new tools, introducing new technology, process-related changes, new technical initiatives, new strategies, etc.
  4. What were the previous release retrospective action items, and do any of them still require any further action?
  5. Come up with an action plan for the new goals identified in the current release retrospective.

We could use a simple agenda for holding the release retrospective, as shown below. Every organization could have its own specific agenda/structure, based on the nature of the work.

Release Retro.jpg
What are the advantages of release retrospectives?

  1. Get a high-level overview of the big picture
  2. Evaluate the release and come up with a high-level look-ahead plan for the next release.
  3. Evaluate the release with regard to the key focus areas (process, technology, quality, etc.), and come up with a strategy for the next release.

Note: Some teams do a release retrospective in which all the teams and team members are involved. Norman Kerth’s book Project Retrospectives talks about a few techniques for running a large-scale retrospective in which many people are involved.

Originally Posted by Madhavi Ledalla @ Scrum Alliance on 29 September 2014