Running effective sprint retrospectives isn’t as easy as getting your team together and deciding what to start, stop, and continue doing in future sprints.
First, there are scheduling conflicts — getting everyone to agree on a time is increasingly challenging, especially with teams who are running remote retrospectives that need to accommodate employees in different timezones.
Then there’s the issue of not following through on action items — a lot of good ideas come out of retrospectives, but the problem is plenty of those good ideas end up staying there. This is because there isn’t a clear transition from sharing feedback in the retrospective to seeing that feedback implemented in the next sprint. By the time you’re in your next sprint, your team is back to old habits.
There are two strategies you can implement to overcome these obstacles:
- Start running asynchronous sprint retrospectives
- Stagger those asynchronous sprint retrospectives over multiple days (more on the “why” behind this later).
We didn’t pull the two strategies above out of thin air. Danny Varner, Director of Engineering at Vacasa, wrote a blog post about how he has used this very format to run effective, asynchronous agile retrospectives that are spread out over multiple days. We sat down with him to get additional insights into his process, and we’ll detail how it works in this post.
Note: Learn more and sign up for a free 30 day trial of Geekbot to run asynchronous retrospectives, daily standups, and other remote work check-ins in Slack.
Table of Contents
- Collect Data on Day One
- Glean Insights on Day Two
- Decide What to Do on Day Three
- Commit and Close the Retrospective on Day Four
Collect Data on Day One (Monday)
On the first day of your sprint retrospective, you (or whoever is taking their turn as the facilitator) will gather data from your team by getting their answers to the three standard retrospective questions.
- What is going well with the team right now? What should we continue doing?
- What’s not going so well? What continues to be a pain point?
- What should we do differently? Any suggestions for change?
You can use Geekbot (our asynchronous meeting tool that integrates with Slack) to send out these retrospective questions. Team members get a notification (based on their specific timezone) in Slack and can answer Geekbot asynchronously when it’s most convenient for them. Then, the retrospective answers get posted in a public Slack channel.
By asking these questions asynchronously via Geekbot, you give your team time to answer thoughtfully, at their own pace (rather than at an inconvenient, synchronous time).
We also know sometimes Slack messages can get overlooked. So don’t worry if your team member forgets to answer their questions, as Geekbot will follow up, reminding them to provide their feedback.
Note: Geekbot’s reminder feature is completely optional, and you can turn it on or off based on your team’s preferences.
Glean Insights on Day Two (Tuesday)
For the second day, take the insights you learned from the first day and consolidate them. Then you can put them in a poll (see screenshot below) and send that poll to your entire team. What you’re looking for is input to help your team pick which three things are the most important for the next sprint.
Note: This screenshot is of Simple Pool; now Geekbot is happy to offer poll and survey functionalities.
A benefit of staggered retrospectives is now your team has had a day to distance themselves from the feedback they offered on Monday. They’re looking at everyone’s insights with fresh eyes. Every issue your team members will bring is important — but the goal is to prioritize the things that carry the most weight for the team, which may not be the item that carries the most weight for the individual.
By seeing the responses written out — and by waiting a day — team members are more likely to weigh each option objectively before voting. Plus, by seeing the options side-by-side, team members are given context — what they think is the most important feedback may change based on the options in the poll.
Decide What to Do on Day Three (Wednesday)
The results of the poll make it easy for you to decide the top three things that need to be prioritized in the next sprint.
But you’re not done yet. You still need to make sure your team is invested in solving these issues.
With Geekbot, you send out another round of questions. This time you pair the top three issues that need solving with the question: what is something actionable we can do to change this issue?
Commit and Close the Retrospective on Day Four (Thursday)
It’s day four of your staggered retrospective. Your team has filled out the answers asynchronously when it was convenient for them. The entire team has voted on what’s going to be a focus for the next sprint and offered actionable items that can be done to solve those areas of focus.
Again, you take your team’s own answers, put them into an actionable proposal and send out another poll to your team, asking them: which actions from our retrospective will you do in the next 2 weeks?
Each stage of the four day process builds on each other, and this retrospective process is geared for getting follow through on the action items that matter most (based on the vote of the team).
To sum it up:
- Day One: Collect data from your team via the standard 3 retrospective questions.
- Day Two: Consolidate that data and gather valuable insights by polling your team on what three items are the most important for the next sprint.
- Day Three: Take the three items that your team voted on as “most important” and then ask them for actionable ways to address each item.
- Day Four: Finally, send out one last poll. With this poll, you’re increasing the chances of implementing retrospective learnings by asking your team to pick which action they’re committing to taking on in the next 2 weeks.
Final Thoughts on Running Sprint Retrospectives
There isn’t a must-follow template for running a Scrum retrospective, but it does provide an overarching goal: learn from your most recent sprint what was working and what was not so you can fix it in the next sprint.
One of the best ways to implement that goal is by holding asynchronous sprints that are staggered over multiple days. This way, not only do you avoid scheduling conflicts, but you also create a retrospective format that allows time for introspection and creates a culture of continuous improvement.
Note: Learn more and sign up for a free 30 day trial of Geekbot to run asynchronous retrospectives, daily standups, and other remote work check-ins in Slack.
Frequently asked questions
Who Attends the Sprint Retrospective Meeting?
A sprint retrospective is for whoever is part of your Scrum Team. This includes your development team, the Scrum Master (who may or may not serve as facilitator), and the Product Owner.
Because the sprint retrospective touches base with so many team members, it can be challenging to schedule.
With Geekbot’s asynchronous tool, all appropriate parties get a notification when it’s time for them to answer their retrospective questions. If it’s not a convenient time for them, they can snooze the notification and come back to it when they’re ready to give their answers.
What’s the Difference Between a Sprint Retrospective and a Sprint Review?
A sprint review happens at the end of each sprint, and its main focus is getting the entire Scrum together to discuss whether or not the sprint goal has been met.
A sprint review is heavily focused on the product that was the center of the sprint.
On the other hand, a sprint retrospective is looking both back at how the last sprint worked as a whole — it’s more focused on the process of the sprint. Sprint retrospectives are meant to improve your team’s development process.
How Do I Run a Sprint Retrospective?
There are several ways to run a sprint retrospective. As we outlined in this article, we think one of the more effective meetings is to combine asynchronous retrospective technology with a staggered, multi-day approach.
This allows your agile team to refine their feedback, provide apt solutions to problems, and commit to what they’re going to do differently in the next sprint.