Retrospective Meeting

The retrospective meeting is a meeting held after an Agile iteration, during which the whole team reflects on the process and what can be done better in future iterations.

Many cultures have adopted some variation of the proverb, “Those who cannot remember the past are condemned to repeat it.” For any process, it’s important to be able to look back at what went right and wrong, to inform future iterations.

That’s why even with so much focus on continuous delivery and the need to constantly move forward, Agile frameworks still include retrospective meetings to discuss the last iteration and how to learn from it.

In this article, we define retrospective meetings, talk about when to hold them and demonstrate the best practices for having one.

What is a Retrospective Meeting?
What is the Goal of the Retrospective Meeting?
When Do You Hold a Retrospective Meeting?
How Do You Host a Retrospective Meeting?
Retrospective Meetings: Informing the Future

What is a Retrospective Meeting?

A retrospective meeting in Agile is a type of meeting that takes place at the end of a given iteration or release cycle. During the retrospective meeting, the whole team discusses the last cycle of work and reflects on what happened. In particular, stakeholders will discuss both what went wrong and how to correct it for future iterations, and also what went well.

Often product managers hold retrospective meetings. However, in Scrum, where the sprint retrospective meeting is one of the Scrum ceremonies, it might be the Scrum master who hosts retrospective meetings.

What is the Goal of the Retrospective Meeting?

The objective of any retrospective meeting is to provide a safe space for every stakeholder to talk about the last iteration. This includes discussing conflicts that arose during the project and criticizing inefficient processes. A properly executed retrospective meeting will facilitate open discussion among all stakeholders and allow everyone to gain new perspectives and insights into what happened. Through these insights, the team can carry out future meetings with past challenges in mind, and therefore prevent issues from repeating.

Of course, retrospective meetings should also include time to praise the process. This not only helps improve morale for the team, but it also provides opportunities to strengthen the parts of the process that you did find effective. Your team may even derive new best practices from the positive learnings which come to light in the retrospective.

When Do You Hold a Retrospective Meeting?

As a rule, the more frequently you hold retrospective meetings, the more effective they become. This is because people tend to forget what happened in past iterations as they move on to the next stage. You can hold a retrospective with every sprint, or even during your daily standup, depending on the type of project you’re working on and its scope.

With that said, retrospective meetings do take up time. Having them too frequently can eat into valuable development hours and also cause additional friction when it comes to transitioning from one phase to the next. That’s why you should hold retrospective meetings within a week of shipping a product, release, or change. In Scrum, sprint retrospective meetings take place after every sprint, to help continuously improve each sprint.

How Do You Host a Retrospective Meeting?

There is no formally codified process for hosting a retrospective meeting, but the most effective ones have these steps in common:

1. Preparation

Start every retrospective meeting by using your collaboration tool of choice. This could be a document, a special board in your task management platform, or even a whiteboard and post-its. Your tool should be able to divide input from your team into three categories:

What worked
What didn’t work
Concrete actions for improvement

You may also consider asking a third party who wasn’t involved in the iteration to host the meeting. This can help prevent any feelings of undue bias.

2. Create the safe space

Set the rules for your meeting. Make sure that everyone knows:

Not to take it personally
That everyone is going to get their chance to speak
That they should respect and listen to someone whose turn it is
That the goal isn’t to pass the buck, but uncover how to improve
That open communication is the goal here, and that no one should be afraid to admit mistakes or call out bad processes

3. Talk about the entire process

During your discussion, you should provide everyone with the opportunity to speak about any aspect of the iteration. That doesn’t just mean development or engineering work. Also discuss deadline management and how things were documented. As wekk as the quality of communication between team members, and even your marketing efforts.

4. Discuss concrete steps your team can take to improve

Highlighting any issues is only one half of the equation. The other equally important step is to identify what can be done to prevent them from arising again. Your team should work together to figure out answers to the most common questions or problems.

You can treat the action items that you develop from the retrospective as their own project. Give each action item a certain priority level based on its impact on the next sprint. The items should also have their own task owners and due dates so that there is accountability for addressing each issue. You can review the progress you’ve made towards resolving each issue during the next retrospective meeting.

5. Review and follow up

The action items that you generate during the retrospective should be tackled with a genuine effort to improve the process. To ensure that they’re being worked on, you can have a brief follow up session with each retrospective meeting.

Here, you can review all the past issues, whether they’ve been resolved or are repeating. You can also see the progress of the resolvement of issues and blockers, and whether positive feedback from the last retrospective still applies.