Retrospective

Updated: September 29th, 2023

Fact checked by: Kirsty Kearney Greig

Product management glossary / Retrospective

What is a retrospective?

A retrospective, often referred to as a ‘retro’, is a structured and collaborative meeting held by product and development teams, particularly in Agile methodologies. It was made famous through the original Scrum Guide. The purpose is to reflect on a recent period of work and identify opportunities to improve the process. Some of the benefits of running a retrospective include:

Encouraging continuous improvement through the discipline of inspect and adapt
Allowing your team to review their accomplishments and processes
Giving space for your team to evaluate and overcome their challenges
Enhancing your team’s future performance

Although first used formally within product and development teams, the concept and format of retrospectives have expanded out to general project teams. It’s common to find project teams from myriad departments and functions holding retros at the end of certain projects.

What is an agile retrospective?

An Agile retrospective is a specific type of retrospective commonly used in agile methodologies like Scrum and Kanban. It focuses on evaluating the Agile team’s performance during a specific time frame, usually a sprint, and aims to enhance teamwork, processes, and product quality.

Agile retrospectives are instrumental in fostering continuous improvement within agile teams.

What is a sprint retrospective?

A sprint retrospective is a subset of agile retrospectives, primarily associated with Scrum. It occurs at the end of a sprint, which is a time-boxed development cycle in Scrum.

It allows the product team to review their sprint’s accomplishments, challenges, and collaborative efforts. The insights gained help in refining the team’s approach for the upcoming sprint.

The outcome of each sprint retro is a list of things to try or actions to take to make things better. Ideally these are in the form of experiments to review in subsequent retros for keep, change, or bin off decisions. Hence retros drive continuous improvement. What’s not to like?

Why are retrospectives important?

Just shipping something and moving on, ship and move on, ship and move on, is a sure-fire path to repeated mistakes and a whole pile of technical debt. Taking the time to pause, look back and evaluate what you did and how you worked, with the express purpose of finding ways to improve the process next time, will ensure you’re getting better with each and every sprint, cycle or project.

In this way, retrospectives are crucial in product development because they enforce the principle of continuous improvement.

They enable teams to:

Learn from past experiences.
Identify and address issues proactively.
Enhance collaboration and communication.
Increase product quality.
Boost morale and motivation.

What is a retrospective meeting?

A retrospective meeting (‘retro meeting’) is the vehicle for these retrospectives. Since retros are, by their very nature, a collaborative undertaking, they require multiple team members to come together and share their feedback and ideas. These meetings are key to the retrospective process.

During a retrospective meeting, team members discuss their experiences, successes, and areas for improvement openly and constructively. The primary goal, as we’ve already said, is to identify actionable items to enhance future work.

Who should attend a retrospective meeting?

Retrospective meetings should ideally include all members of the team directly involved in the project or work being reviewed, this includes:

Developers
Designers
Product managers
Scrum Masters
Agile coaches.

Depending on the scope of the project you might want to get a wider group of people together with representatives from all functions involved in the project – sales, marketing, customer success and support.

If you’re doing a larger, full project retro then it’s essential to have a diverse group to gain varied perspectives and insights.

Who should run a retrospective?

Commonly retrospective meetings will be run by a Scrum Master, Agile coach or a Product Manager or Owner.

However, choosing the facilitator for your retro meeting is less about job title and more about being impartial. You should also choose someone with the right skills and knowledge. A good retro facilitator will:

Be a good time keeper and ensure the discussions move at the right pace
Be a good listener, understanding the point each participant is making and recording it accurately
Not be afraid to police any blame or criticism should any emerge
Ask questions to dig deeper and encourage the most productive discussions that result in tangible actions

How often should you hold retrospectives?

The frequency of retrospectives varies depending on the team’s needs and the project’s duration, but is commonly held at the end of each cycle in Agile methodologies.

A team can adapt the timing to their needs though, such as conducting retrospectives after major project milestones or on a regular cadence, like monthly or quarterly.

You could also do a combination of both regular sprint retros with the development team, and wider all-function retrospectives after longer-term, major new features or products have shipped.

How to run a good retrospective meeting

There’s definitely an art to running a really great retro meeting. And certainly, if you and the team are new to retrospectives, your meetings will get better over time. So don’t expect your first retro to be perfect – you’ll need some time to smooth out the agenda and process and for everyone to feel completely comfortable and willing to openly share without fear of any negative impact.

But don’t worry, it’ll come. In fact, why not run a retro for your retro!? There will always be things you could do better.

In the meantime, here are some top tips for running a good retro.

Give everyone equal floor time

It’s important that everyone has an equal opportunity to share their thoughts and add their contribution. So don’t have your facilitator address the whole group and ask people to shout out their thoughts – actually go around the group one-by-one, asking each person every question.

In fact, it’s a good idea to allow time for everyone to write their points down on post-its (virtual or otherwise), then come together to group them into themes. Then you give everyone time to speak on their point and encourage them to contribute to a point raised by someone else.

It can be helpful to run a quick ice breaker at the start of your retrospective to get people talking about neutral things. This should encourage more speaking when it gets to more complex things.

Remember, all teams are likely to have a mix of personalities with differing comfort levels when it comes to speaking up. So it’s important that those who love to talk don’t steal the floor and those who like to keep their head down miss the chance to speak.

Ensure there’s psychological safety

Retrospectives depend on full and frank, open discussions about the good and the bad. In order for that to truly happen you have to create a safe environment without blame or fault finding. No one should feel singled out or exposed during a retro.

We would recommend, during the scene-setting opening 5 minutes of the meeting, reminding people of that and asking everyone to leave egos at the door and non-constructive criticism to themselves.

Celebrate wins

Don’t focus on negatives alone – make sure it’s also a time to celebrate wins. One of the benefits of a retro is how it can help to boost morale – that can be achieved through taking this time to discuss what worked well, but also the fact that everyone is being given a voice and their opinions are being heard.

Stay focused on process

There’s a tendency for retros, especially sprint retros dominated by development team members, to end up being technical retrospectives rather than looking at process. This isn’t surprising, it’s often easier to talk about the technical stuff. Thinking about process and being critical of how you work doesn’t always come naturally to people. So another tip for running a success retrospective is to ensure your facilitator flags where you’re veering away from process and work to bring it back.

Remember actions to repeat what went well

When it comes to devising the actions to take away from the meeting, don’t forget to think about the positives as well as the negatives. Instinctively you’ll want to come up with ways to ensure the ‘what didn’t go well’ things don’t happen again, but you should also spend some time thinking about ways to repeat the wins.

If something went particularly well during this sprint or project, how can you adapt your processes to ensure that happens each time?

Capture the actions

It’s crucial to document the retrospective’s outcomes. This can be done using various methods, such as creating action items, maintaining a retrospective board, or using specialized retrospective software tools. Capturing the results of your retros with clear actions recorded will help ensure that those all-important identified improvements are actually acted upon.

Questions to ask during a retrospective meeting

The concept of a retrospective meeting is actually a very simple one. The format is well defined and tried and tested. There are just a few questions that form the agenda of any good retro, from which fruitful discussion should flourish.

It is up to the facilitator to ask each question in turn, addressing each participant one after another.

The crucial questions to guide any retrospective discussion are:

What went well?

Reflect on successes and achievements during the period.

What didn’t go well?

Discuss challenges, obstacles, or issues faced.

What can we do better?

Identify opportunities for improvement and growth.

What ideas have we got for next time?

Brainstorm innovative approaches and strategies

How will we implement these ideas?

Determine actionable steps (also known as actions) to implement the suggested improvements effectively.

What can we see in the future that might affect how we work?

e.g. Your QA specialist is going to be off on leave next month, how do we try and minimise the impact and keep delivering?

How long should a retrospective meeting be?

A traditional Scrum retro is 45 minutes for each week of sprint length. That’s the official answer, but in reality, retros can be as long as you need to sensibly discuss the processes you’ve been using as a team, answer all the questions – what went well, what didn’t go well – and agree things you want to start doing, stop doing and continue doing.

The duration of your retro might depend on the size of your team and the complexity of your project. It’s essential to strike a balance between thorough discussions and not making the meeting too lengthy. No one wants to sit in more meetings, and nothing good comes out of the second or third hour of any meeting!

You should consider the length of your cycle and therefore the frequency of your retro meetings when deciding on meeting duration. If you work in two week sprints, then you’ll probably want a retro every two weeks. If that’s the case, you’ll want to keep the meetings shorter than one you might run at the end of a six week project.

Common mistakes to avoid when running a retro

While retrospectives can be highly valuable, there are common pitfalls to watch out for. So, our final piece of retrospective advice (which we’ve gathered from running retros on our retros) is to avoid the following:

Blame and finger-pointing

Focus on process and teamwork, not individuals and their work. And be really strict about this!

Skipping retrospectives

Consistently holding retrospectives is crucial for continuous improvement; skipping them can lead to stagnation. Protect your retro time like a lioness protecting her young.

Not following up on actions

Identified actions should be tracked and implemented; neglecting this step diminishes the retro’s impact. If you don’t action the actions you’ve wasted your time.