Product Templates: Retrospectives

Editor’s Note: the following Retrospective Meeting Template has been validated by The Group Product Manager at Google and Senior Product Manager at Shift.

How many times have you made the same mistake twice? Well, if you are a Product Manager, we hope the answer to that questions should be a big sounding “Not too many,” and likely that will be thanks to Retrospectives.

During 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 

A sprint retrospective meeting –also called an Agile retrospective– is a brief exercise where scrum team members discuss what could have made the last sprint/scrum more efficient. 

Its 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.

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 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.

Timing 

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

Step by Step

Step 1 – Attendance and engagement

  • For a Sprint 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 Scrum master’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 Sprint.
  • 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 – Sprint review

  • The complete 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 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 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 Scrum master 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 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 Scrum master 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 Sprint Retrospective, it’s important to take five minutes to discuss how the retrospective went. Be open and encouraging of feedback from the team, and in the same way as the Sprint was discussed, look at ways to improve the Sprint Retrospective the next time around. If new tools were used, how effective were they?

Start Now

What are you waiting for? We’ve laid it all out in Google Slides, Coda, and Mural. Pick one and get started today.

On Google Slides

Get started on Google Slides with the Retrospective Template and get your team collaborating in no time. Gain instant access to the template here.

On Coda

Learn how to run inclusive meetings in 30 meetings with the Retrospective Template created by our Coda friends.

On Mural

Evaluate and evolve your work using the Retrospective template created by MURAL

Main Takeaways

  1. Save space to reflect on how your sprint went.
  2. Keep a safe space that is blame-free.
  3. Keep it scoped and focus on goals that you can document and commit to addressing.
  4. Keep the retrospective tone lightweight and the goals short and actionable.

Need More Templates?

Still, looking for some great templates? Check out our collection:

Product Template: Product Requirements Document
Product Template: Roadmaps
Product Template: Retrospective
Product Template: User Personas
Product Template: Customer Journey Maps
Product Template: User Flow

We add new templates and frameworks to our Product School Pro community every month. Come join us!

productcon banner

Enjoyed the article? You may like this too: