You’ve finished your sprint. Phew! 😅 It was an intense week, two weeks, or month. No doubt, there are things that could’ve gone better, as well as things that the team did well. But there’s so much still on the product backlog that needs to get done! You have to start thinking about the next sprint, especially if you’re the product owner…
That’s the problem that the sprint retrospective solves: It forces you to slow down, reflect on the previous sprint, and learn from it. Sprints are intense, at times stressful, which is all the more reason to take the time to analyze them so that you can make future sprints smoother and more productive.
If only sprints could always be this smooth…
In this post, we’re going to look at 6 tips you can start using right away to improve your sprint retrospectives.
What is the Sprint Retrospective?
Let’s start by clearly defining the term. The sprint retrospective is the final ceremony in the Scrum methodology. It’s where the team discusses the last sprint – what went well and what could be improved – with the goal of improving future sprints. (By the way, don’t be confused if you see this referred to as the “Scrum Retrospective” – they’re the same thing.)
After a sprint, the Scrum team can be tired, and it can be tempting to skip the retrospective to give everyone a break or leap right into the next sprint. But the retrospective can be incredibly valuable when done right. They help you avoid repeating mistakes, help the team work better together, and make future sprints more productive and less stressful.
Let’s now look at 6 tips to improve your retrospectives.
Tip #1: Come Prepared
The two guiding questions for a retrospective are:
- What went well?
- What can be improved?
Before the retrospective, it’s a good idea to give these questions some thought – ideally, you have some answers for them going into the retro.
By providing you with specific data in easy-to-parse charts and metrics, LinearB’s Project Delivery Tracker gives you the insights you need to answer these questions quickly and accurately.
At a glance, you can see how much you accomplished during the sprint, your planning accuracy, what kind of work you accomplished (were you spending time shipping new features or fixing bugs?), and how much work went into particular issues.
Your CEO will love this! You can see your team’s investment profile, project allocation, and planning accuracy by boards, epics, labels or custom fields. Learn more about Project Delivery Tracker.
Tip #2: Establish the Right Tone
The retrospective can be intimidating. Because it requires people to point out what could be improved, it can feel like people are being forced to criticize their teammates in front of everyone. And it can feel like you’re being required to sit and endure the criticisms other people have about you!
This is not at all the goal of a retrospective. It is not about individuals; it is about the team. How can we, the whole development team, do better in future sprints? Emphasizing that you’re all in it together and no one is being singled out can help put people at ease and encourage them to engage in the retrospective.
It’s important as well to encourage your team to not be afraid of putting forth ideas that they may think are too radical. For example, maybe someone thinks that the length of your sprint should be changed, which would require quite an extensive overhaul of process, expectations, and schedules and would require some getting used to! This may at first seem extreme, but after discussing it, your team may come to agree. That’s why it’s important that the idea is shared in the first place so that it can be evaluated.
On the Dev Interrupted podcast, Shankar Ramaswamy, Head of Engineering at DataStax, recently talked about how it is important to have difficult conversations early and to listen to the other person or people in those conversations. That wisdom certainly applies to retrospectives.
Atlassian, makers of Jira, recommend actually reading out a quote by Norm Kerth about retrospectives at the beginning of each one to help set the right tone:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Norm Kerth
Tip #3: Structure the Conversation
Sprint retrospectives are meant to be organic, free-flowing conversations. However, this doesn’t mean that the conversation should flow wherever it wants. Having some guardrails can help to keep the conversation driving at the right things.
A popular method to structure the discussion is Start, Stop, Continue. You begin by handing out a stack of post-it notes to all the members of team. Everyone writes down what they believe the team should start doing, one idea per note, and then they put all their notes together on the table or on the board. You do the same thing again for stop (what should the team stop doing?) and continue (what should the team continue doing?).
- Start: What should the team start doing?
- Stop: What should the team stop doing?
- Continue: What should the team continue doing?
Once all the ideas are written down, you go back through each group and try to find common themes and ultimately formulate 2 or 3 clear action items.
Tip #4: Set Goals for Your Team
Once the Scrum team has decided what they want to start/stop/continue doing, you can then set goals. You need specific goals so that you can determine whether you’re meeting them or not. For example, the goal “Be more responsive” is not as actionable (and therefore less likely to bring about change) than the goal “Review Pull Requests 50% faster.”
LinearB’s Team Goals feature helps you set goals and track your progress against them. You can set goals for key metrics like pull request size, review time, the riskiness of a PR, and many others, with more yet to come. You can then leverage our WorkerB automation bot to do things like alert you when a big PR is created or a review is taking a long time so that you can intervene.
But how do you know where you’re under-performing in the first place? That’s why we also established Engineering Metrics Benchmarks. We analyzed over 2,000 teams to break down performance along 9 metrics.
Want to learn more about being an elite engineering team? Check out this blog detailing our engineering benchmarks study and methodology.
Tip #5: Use Objective Metrics
Team Goals is not the only place in LinearB to keep track of metrics. We also have the Metrics Dashboard, which is where you can set up a custom dashboard that updates in real-time to keep an eye on metrics of concern. In addition to the metrics already mentioned, you can track Cycle Time, and its constituent parts, as well as all the DORA metrics, including deploy frequency and Mean Time to Restore.
LinearB provides DORA metrics right out of the box so you can discover your DORA metrics in minutes. Get started today!
Tip #6: Set Aside Time to Improve the Sprint Retrospective Itself
Don’t forget that the sprint retrospective is itself part of the sprint process that can be improved! In practice, this means setting aside time during the retrospective to talk about how retros specifically can be better. Maybe someone has an idea for a better method than Start, Stop, Continue or perhaps some people feel that previous retros have been tense and they want to reset the mood in the team. Whatever the case, it’s important to create the space for sprint retrospective ideas, and specifically ideas for sprint retrospective improvements, to be shared and discussed.
Conclusion
Although the sprint retrospective is the last Scrum ceremony, it certainly is not the least. This is because the learnings from a retrospective have enormous leverage; they can be used to improve every future sprint. Continuous improvement like this can end up compounding as well: If you avoid making the same mistakes, you can improve in area after area.
LinearB helps you to get more out of your retrospectives. With specific metrics, you can have deep visibility into how the sprint unfolded, instead of just seeing which items in the sprint backlog weren’t completed. With the help of the benchmarks we’ve established, you can set goals, track your progress toward those goals, and leverage tools like WorkerB to help you improve.
And you can do all this within one platform that you can get set up in minutes.
