Retrospective means to look back - in the product cycle, these typically take place after a launch so you can assess what went well and what didn't so you can improve next time around.

During Product Retrospective Meetings, teams discuss what worked, what didn’t, or what could have been better at the end of every sprint.

By adopting these practices, teams become more likely to experience continuous growth, learn from failure faster, and anticipate issues by identifying them early.

Retrospectives 101 

Here are the most common types of retrospectives:

  1. Sprint retrospective: Also called an Agile retrospective. This is a brief exercise where scrum team members discuss what could have made the last sprint/scrum more efficient. The goal is to allow the scrum team to reflect on the sprint and determine how they can use that knowledge to improve future sprints. In essence, it is a meeting where the previous sprint is discussed.
  2. Incident retrospective: A history of previous retrospectives where you can allocate accountability for previous action items and plan accordingly. Usually you would want to run this with the retro lead walking through what happened in a timeline and then cycle through each person to walk through their pre-work.

Why Do You Need Retrospectives? 

The driving principle for the Product Retrospective is that a team can always do better and should always be looking for ways to improve. And a successful retrospective will generate outcomes that are quantifiable actions. 

It’s not enough to recognize what went well or what problems were encountered. One has to create a list of commitments for further iterations to improve the team’s performance in the long term.

When should you hold an Agile Retrospective?

Sprint retrospectives usually happen at the end of each sprint and help build a robust scrum framework through continuous improvement. This helps make the next sprint planning much more comfortable for the scrum master/product owner/whoever runs the next sprint/scrum.

They’re best applied in environments where a set team works on multiple projects or iterations.


A retrospective should not take more than two hours and includes the entire team and a facilitator.

person wearing bright orange shoes walking up bright blue metal steps

Step by Step

Step 1 – Attendance and engagement

  • For a Product Retrospective to be worth the effort, the entire team must be involved. That means that everyone must be present and take part in the event. After people have completed several previous retrospectives, they are liable to lose interest and not contribute. It’s the facilitator’s job to ensure everyone stays engaged, and they should be ready to change direction if they feel that their initial techniques are not working. It’s also essential that all participants feel free to express their honest opinion, free from the threat of retribution.
  • At the same time, a Product Retrospective’s goal is not to point out individual people’s mistakes but to figure out how the team can improve. As such, all participants need to accept that everyone did the best work they could, given their skills and knowledge at the time.

Step 2 – Review

  • The complete Product Retrospective should only take an hour and a half, with most of the time dedicated to discussion. To aid that, a quick summary should be provided of the sprint or incident in question. 
  • Mention key facts, such as what the plan was, how it was followed, and what the outcomes were. This brings everyone onto the same page and gives people a feeling for whether the Sprint or previous retrospectives were a success or not from a measurable standpoint.

Step 3 – Discussion

  • The discussion is the central part of any Product Retrospective. It can be very open-ended, so it’s best to use predefined tools and methods to ensure proper outcomes are met. The facilitator should use the tools that they’re most familiar with and that they feel will prove most useful. 
  • Most tools focus in some way on what the team feels went well in the last iteration, what they need to stop doing, and what different things they can try for the next iteration. Ideas should be generated by the team and recorded for evaluation. Reference can also be made to actions as defined in a previous retrospective.

Step 4 – Actionable commitments

  • The main goal of the retrospective is to identify what actions must be taken in the next iteration. From the ideas discussed, the team should determine measurable steps that they can implement.
  • When we say measurable, what we mean is: it’s not enough to say that code reviews need to be done more quickly. Instead, a value must be assigned to the statement. For example, all codes must be reviewed within 4 hours of submission. This way, it is clear to tell whether an item is achieved or not and gives team members a set goal to work towards.
  • There must be a consensus among the team on the final actions. Your result should be a list of fewer than ten items, preferably five, which the group agrees to work on, and will aim to achieve for the next Sprint.

Step 5 – Retrospective retrospective

  • At the end of your Product Retrospective, it’s important to take five minutes to discuss how it went. Be open and encouraging of feedback from the team.


“We knew that we had to take a retrospective look at our product after the latest launch proved to be less successful than anticipated.”

“Product Mindset: How to Get Inside Your Customer’s Mind”