How to Run a Product Retrospective
Never make the same mistake twice
Hi, Product People! Carlos here. How many times have you made the same mistake twice? Well, if you are a Product Manager, we hope the answer to that is, "very rarely." And that’s thanks to product retrospectives!
During retrospective meetings, teams discuss what worked, what didn't, or what could have been better at the end of every project.
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
A retrospective meeting is a brief exercise where product team members discuss what could have made the last project more effective.
The goal is to allow the Product team to reflect on the experience and determine how they can use that knowledge to improve future projects. In essence, it is a meeting where the previous project is discussed.
Why do you need retrospectives?
The driving principle for the 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 a retrospective?
Retrospectives usually happen at the end of a project or sprint and help build a robust framework through continuous improvement. This helps make the next roadmap planning and execution much more comfortable for whoever runs the next project.
They’re best applied in environments where a set team works on multiple projects or iterations.
Timing
A retrospective should not take more than two hours and includes the entire team and a facilitator.
Step by Step
Follow along with this free Product Retrospective Template
Step 1 - Attendance and engagement
For a 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 retrospective leader’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. If someone is afraid to discuss a problem, it will remain a problem for the next project.
At the same time, a 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 - Project or sprint review
The complete retrospective should only take an hour and a half, with most of the time dedicated to discussion. To aid that, provide a quick summary of the project 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 project was a success or not from a measurable standpoint.
Step 3 - Discussion
The discussion is the central part of any retrospective. It can be very open-ended, so it’s best to use predefined tools and methods to ensure proper outcomes are met. The retrospective leader 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 project or sprint.
Step 5 - Meta retrospective
At the end of your retrospective, it’s important to take a couple minutes to discuss how the retrospective went. Be open and encouraging of feedback from the team, and in the same way as the project was discussed, look at ways to improve the retrospective the next time around.
Check out some of the previous issues:
The timing of the retro can be interesting. I’ve tried a few ways:
1. Finish the epic on a Friday and immediate retro
2. Finish the epic on a Friday, release Monday, retro after release
3. Schedule a recurring mid-sprint retro (for previous sprint), on a Wednesday
And more.
I recently tried the Shape Up methodology. With this, we finished our cycle on a Friday and had to make a decision on the retro. I deviated a little bit and held my retro the Monday after (nice weekend to relax) but _before_ releasing the cycle into prod.
I found if you put the retro _after_ the release, things might have gone wrong during release (unrelated to the work done during the cycle), in which case the devs involved in the cycle+release are the wrong state of mind for the retro.
Just my 2c!