Sprint Retrospective Meetings – Tips, Techniques, and Examples

This article includes an excerpt from our ebook. For the full guide to building a collaborative software team, pick up your free copy!

You’ve done it. The milestone ended. Code was tested and shipped. One of your programmers grew a beard. No one expected mutton chops from Martha, but your team is being very supportive of her choices.

All in all, it was a successful sprint. Now it’s time to take stock, analyze your work, and fine-tune your process so your next sprint is even more successful. From thousands of hours of customer coaching, we’ve curated a list of easy-to-implement tips and best practices to show you what needs to be done after a sprint.

What is the purpose of a sprint retrospective?

A sprint retrospective is a way to reflect on the previously completed sprint and gain insights into how well the team worked together. Retros are meant to be honest and open discussions intended to encourage learning from past errors, optimize processes, and see continuous improvement from the team.

What is a sprint retrospective meeting?

A Scrum Master organizes retrospective meetings to get a development team to discuss the past sprint and what can improve in the future. A retro meeting’s primary purpose is to help everyone develop their workflow by using objective team feedback as a tool. These meetings generally last between 30 minutes to an hour and cover topics like team communication, the code review process, team alignment, and digital tools or frameworks used to conduct work.

The three general questions that you need to answer by the end of the meeting are:

1. What went well during the sprint?
2. What went wrong?
3. What have we learned that would improve the next sprint?

When are sprint retro meetings held?

Retro meetings are one of the 5 scrum ceremonies, typically happening right after the sprint review, which occurs at the end of each sprint. People often get sprint reviews and retros confused, but they do not serve the same purpose or include the same group of people in them.

What is covered in a sprint review?

The purpose of the sprint review is to present the team with an update on what was completed in the previous sprint, demo releases, and receive feedback. This is the perfect time to bring in other people, like designers, executives, marketers, salespeople, and customers. Bringing new perspectives into the review allows the team to better iterate on their work and plan for the next sprint.

What is the difference between sprint reviews and sprint retros?

Essentially, the difference between sprint reviews and retros comes down to who attends the meeting and its goals. Reviews are meant to showcase the work accomplished to the wider team. Conversely, retros are meant to reflect on processes and how the development team worked together to identify areas of improvement.

What are appropriate topics for discussion in retrospectives?

Retros typically cover the topics of:

• Did we accomplish everything, or did we take on too much?
• Why did we not finish some of the tasks that were assigned?
• Were the original story point estimates we assigned accurate? (i.e, what unanticipated challenges impacted our estimates that we should address in the future?)
• Anything we want to change or stop doing for the next sprint?
• What worked well or did we like about this sprint that we want to carry over to future sprints?
• Do we need more resourcing?
• Any other comments on processes, how the team collaborates, issue estimation, etc.

How to run sprint retrospectives and best practices

1.  Start the meeting by reviewing closed issues

Your dev team may not close every issue. So, ask yourself: Are issues open because your team didn’t have enough time or because they’re no longer relevant? Whatever the answer, don’t just leave your leftover work in your sprint backlog. Take 10 minutes and review what was finished or closed during the sprint.

Whether issues were shipped, closed, or no longer relevant gives the team context of what was worked on versus what was committed to. This provides a framework for discussing what went well and didn’t, so prompt your team to share lessons learned.

Here are some questions you can ask:

• Did you effectively estimate the issue? This would help benchmark if you were accurate during Sprint planning.
• Is there anything that came up in the code base as you developed the feature worthwhile to share with the team?

It’s essential not just to say what was closed or missed but to focus on anything unusual. For example, you estimated work as a 3, and it was completed, but it was actually quite complex. It would help if you shared what risks came up mid-flight and discussed as a team how to surface these going forward for new Issues that might have similar risks.

2.  Review open issues and discuss why completed work is still open

This helps build habits and reminders that people should update work as the update is available (and will help keep the burndown chart updated in real time!).

If you constantly find yourself with a lot of open Issues, be sure to ask:

• Did something creep up that made this issue too complex to complete within the sprint?
• Is this still a priority against the other Backlog items?
• Is the estimate on this issue still accurate? Did we identify something mid-Sprint that changed this estimate, which is why it wasn’t completed?

Start, stop, or continue

During the meeting, ask each team member to name things they should start, stop, and continue doing. “Continue” items are the things that are helpful but aren’t yet habits. Mark these in your GitHub issue. To stay accountable, open each meeting with a 5-minute review of the previous sprint’s issue. Ask the team: did you stop, start, and continue the things you said you would?

3.  Use Github labels for your research, moonshot project, or experimental issues

If you’re working on a piece of code for an experimental project, something that might be thrown away, or is going through research (also known as Spikes) to find the best way to move an Issue forward, be sure to label these issues in the sprint. Labels are a great way to understand how much time is spent on this particular type of work in a sprint. We recommend using labels for groupings within sprints so your team can use the velocity chart to understand throughput against different issue types.

4. Keep meetings focused and actionable

It’s always better to have a couple of high-value action items than a bunch of vague ones. Identify a few things your team will do differently in the next sprint, mark them in GitHub, and remember to follow up next time to evaluate how it went.

We close our retros by verbally repeating our actionable items and stating who the keeper is. A lot can come up during these meetings, so this final step helps cut through the clutter and ensures everyone understands who is responsible for what.

5.  Look for the causes of particular situations or problems

Of course, the value in reflection isn’t just about identifying what you did well; it’s openly discussing problems and areas of improvement. It can help you figure out what happened, why it happened, and what steps you can take to prevent it from happening again.

The first step of root cause analysis is to identify the problem: what areas of concern arose during the sprint? How and why did you recognize it as a problem? Next, collect data: How long has the problem existed? What was its impact? After that, try to identify the causal factors: What events led to the problem? What other issues sprung up because of it?

Try asking “why” a few times.

• Why did X happen? (Because of Y.) Why did Y happen?
• Why is X a problem?
• Why did we not see X happening until now?
• Why did no one report on X?

It feels repetitive, but you’d be surprised how repeatedly asking “why” digs up root causes that nobody would have thought of. Finally, figure out the actions you’ll take to prevent the problem from happening again.

6.  Help the team feel comfortable being honest

The core of any successful retro is honesty. A lot of these conversations may feel challenging, but they don’t need to be. If your team is anything like ours, nobody wants to point fingers. To address this, encourage a non-judgemental environment focused on continuous improvement and information-gathering. Set the tone by establishing a safe space; for example, open the meeting by giving out +1s for recent wins or using “we” when discussing problems instead of “you” pronouns.

The intersection of caring personally and being willing to challenge directly is what Kim Scott, a leadership expert, calls radical candor. Scott argues that radical candor – giving, receiving, and encouraging frank guidance – is your moral obligation as a teammate. She says: “Radical candor is humble, it’s helpful, it’s immediate, it’s in-person — in private (if it’s a criticism) and in public (if it’s praise) — and it doesn’t personalize.”

In contrast to radical candor, most of us fall into a dangerous space Scott calls ruinous empathy – which is to say that we’re so intent on being “nice” that we end up ignoring problems and sabotaging our team in the process. While feedback should be immediate and impromptu, regular retros are invaluable to building a healthy and radically candid team.

Pat yourself on the back

You did it! With these sprint retro best practices and tips, you’ve successfully seen your sprint through to the end, reflected on it, and ensured future sprints go even further. Now get ready to do it all again.

For teams new to story point estimating, we’ve created a helpful guide on how to estimate in agile project management. If you have any questions, you can reach out to our Customer Success team, who are happy to walk you through how to use estimates.