How to Run a Sprint Retrospective Meeting

The 12th principle of the Agile Manifesto states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.

While sprint retrospectives were made popular by software developers, any team can benefit from making them a part of their workflow. After all, no matter how good your team is and how efficient your processes are, there can always be room for improvement.

Let's dive deeper into what a sprint retrospective meeting actually is and how to run it effectively.

• What is a sprint retrospective?
• How to run a sprint retrospective meeting
• Sprint retrospective template

What is a sprint retrospective?

A sprint retrospective, also known as an agile retrospective, is a meeting held by a team at the end of a sprint to review its process and identify opportunities to improve it.

According to the Scrum Guide, written by the founders of Scrum Ken Schwaber and Jeff Sutherland, the purpose of a retrospective is to:

• Inspect how the last sprint went with regards to people, relationships, process, and tools;

• Identify and order the major items that went well and potential improvements;

• Create a plan for implementing improvements to the way the scrum team does its work.

To put it simply, a sprint retrospective should create a safe space for people to share their honest feedback on what's going well and what isn't, and to generate a discussion around what could be improved next time. It's a practice that helps teams reflect on their way of working and continuously become better in what they do.

Here's an example of what a documented sprint retrospective could look like in Nuclino:

Nuclino is a unified workspace where you can not only plan your sprints and run sprint retrospectives, but also build your internal knowledge base, collaborate on internal documentation, onboard new employees, take meeting minutes, communicate asynchronously, and more. It works like a collective brain, allowing you to bring all your team's work together in one place and collaborate without the chaos of files and folders, context switching, or silos.

Sprint retrospective vs. sprint review

Sprint retrospectives are often confused with sprint reviews, but they are not the same.

A sprint review takes place before the sprint retrospective and is used as an opportunity to discuss what has been accomplished during the sprint and whether the sprint goal has been met. It is used to review and plan ways to improve the product, while the sprint retrospective is used to review and improve the processes used to create the product.

Essentially, the sprint review is a discussion about what the team is building, while the retrospective is focused on how they’re building it.

If done well, a sprint retrospective meeting can highlight opportunities for meaningful sprint planning process improvements and move the team in the right direction. If done poorly, it can turn into a blame game or a just another repetitive, time-wasting meeting.

How to run a sprint retrospective meeting

All meetings should be viewed with a dose of healthy skepticism. The unfortunate truth is, most meetings are a threat to your team's productivity rather than an opportunity to make progress.

Is a sprint retrospective meeting worth your team's time or will it end up being just another unnecessary interruption? That depends on how you run it.

Prepare asynchronously

Asynchronous retrospectives are not just for remote teams, and just because you can bring your entire team together in the same room at the same time, doesn't mean you should. Synchronization is always a bottleneck when it comes to team communication, but the good news is – in most cases, it's not needed.

Most of the time, retrospectives can be done without meetings or video conferences. Instead, ask your team to write up their individual retrospectives and reserve real-time, face-to-face communication for particularly challenging issues.

As a result:

• Your team will be able to write down their retros in a thoughtful, structured manner.

• They will have enough time to absorb each other's contributions and provide feedback.

• Everyone will have an opportunity to contribute and document their experiences.

• Every sprint retrospective will be automatically documented in your internal wiki.

Keep face-to-face discussions short (and optional)

While you shouldn't default to a meeting for every sprint retrospective, in some cases it's the fastest way to work through a particularly tough problem.

If you do decide to shift to a synchronous discussion, don't take longer than you need. Some suggest setting the length of a retrospective meeting based on the length of the sprint – for example, a 30-minute retrospective after a weekly sprint and a 3-hour at the end of a monthly sprint.

But not every issue requires a synchronous discussion. Most information can be shared asynchronously and read by every member at their own pace – don't waste time reading it out loud for everyone to listen and nod. Instead, allocate more time to issues that actually require a discussion.

Establish a safe environment for feedback

While it's easy to talk about what went well, what went wrong can be a sensitive topic. No one likes to point fingers, but if problems go unmentioned, the team won't improve as quickly as they could.

There are several ways to encourage your team to be honest and direct in their retrospectives:

• Encourage everyone to write up their thoughts in advance. Team members might be more hesitant to bring up touchy subjects during a face-to-face meeting.

• Make sure every stakeholder contributes to the shared document. If someone's work is going to be discussed, they should have the opportunity to express their perspective.

• If you plan a face-to-face meeting, appoint a moderator to guide the conversation. Ideally, this person would not have a stake in the discussion.

Assign tasks as they come up

The ultimate goal of a sprint retrospective is not just to share information – it's to identify and implement improvements for the next sprint. Make sure to clearly document the outcomes of the retrospective, the decisions you made, and the next steps you planned, giving clear accountability and ownership.

Don't only focus on technical issues

A retrospective is different from traditional post-mortems and project reviews. It doesn't only inspect your team's development process but focuses on the team itself.

According to Agile retrospectives: Making good teams great, "team issues are as challenging as technical issues – if not more so". Don't miss this unique opportunity to identify and address any problems with team dynamics which may impede your work.

Sprint retrospective template

There are many popular ways to run sprint retrospectives, for example, "Start, stop, continue" or "Good, bad, better, best". Whichever style you choose, as long as your retrospective covers the following questions, you're good to go:

• What did we do right in the previous sprint?

• What did we do wrong in the previous sprint?

• What should we start doing in the next sprint?

• What should we stop doing in the next sprint?

• What can we do to improve productivity?

Here's an example of a sprint retrospective template you can use for your own sprints. Copy this template and customize it for your own sprint retrospectives.

Want to see a sprint retrospective meeting in action? GitLab live-streams their team retrospectives on their YouTube channel GitLab Unfiltered:

At the end of the day, there is no "one-size-fits-all" when it comes to running productive agile retrospectives. Depending on your team size and distribution across countries and time zones, different approaches may suit you best. But when done right, regular sprint retrospectives can cultivate a culture of transparency, trust, and continuous learning.

Nuclino: Your team's collective brain

Nuclino brings all your team's knowledge, docs, and projects together in one place. It's a modern, simple, and blazingly fast way to collaborate, without the chaos of files and folders, context switching, or silos.

• Create a central knowledge base and give your team a single source of truth.

• Collaborate in real time or asynchronously and spend less time in meetings.

• Manage and document your projects in one place without losing context.

• Organize, sort, and filter all kinds of data with ease.

• Integrate the tools you love, like Slack, Google Drive, Figma, Lucidchart, and more.

Try it now