A sprint retrospective is one of the most valuable meetings a sprint team has. Even teams that don’t work in a scrum framework can benefit tremendously from inspecting and adapting their processes, culture, and way of working.
However, the Scrum Guide isn’t really prescriptive about what a good retrospective should look like. Lack of structure often leads to unproductive, unsafe sessions that yield no meaningful results.
Properly structuring a retrospective meeting can make a great difference.
While there’s no one-size-fits-all way to structure a retrospective session, one of the most popular and flexible frameworks includes the following five steps:
Don’t jump right into heavy work at the beginning of the meeting. There’s a high chance that people are either still waking up or tired after the day of work. Some probably just jumped from another call and their mind is still in the previous meeting.
Plus, the nature of the retrospective requires setting up a specific mood. After all, you want people to open up, be honest and vulnerable, and openly discuss tough and unpleasant situations.
That’s why you shouldn’t rush into the main part. Ease in.
Invest a few early minutes in letting people transition into the retrospective. For example, ask people to describe the previous iteration in one word or state their expectations for the session. This is an easy way to quickly get participants focused on the meeting itself.
For a successful retrospective meeting, you need data you can inspect. Depending on the retro format, you might gather the data before or during the meeting itself.
The key is to focus on getting facts. It’s not yet time to generate insights, discuss solutions, or, worse, play the blame game.
For example, you can sketch a timeline of the last iteration with all relevant events and situations that happened during the sprint. This visualization will become an artifact that the team can inspect.
Gathering and visualizing relevant facts grounds the team and keeps the discussion focused. Without that grounding, the whole meeting can quickly go astray and jump from topic to topic as new facts are brought to the table.
Once you have all the data gathered, it’s time to look for potential solutions. The principle here is simple: the more, the better.
For this step to be successful, everyone has to refrain from judgment. Even if you are 100 percent sure the idea won’t work, let it be. Insights serve as inspiration for additional insights. Even if a particular solution is impossible to implement, other team members might build on top of the idea and reach a true breakthrough moment.
At this stage, it’s also worth differentiating between working alone and working in groups. On the one hand, groups that work alone generate more insights than groups that brainstorm. On the other hand, sharing ideas often boosts creativity and serves as an inspiration for others. Try to tap into both benefits by swiftly switching between solo work and group work.
If you notice people stop adding new ideas, don’t wrap up the step yet. The best insights often come at the very end, when all the obvious ones have already been proposed.
There are rare situations when it’s perfectly OK to wrap up a retrospective without any action points. For example, sometimes the purpose of the meeting is to:
In these cases, the meeting itself might drive more outcomes than 20 action points. Plus, sometimes it’s less about improving something ad more about letting people vent a bit.
That said, more often than not, retrospectives should yield actionable next steps to drive long-term improvement. Two rules of thumb when making a decision are:
Depending on a specific case, you might want to make a quick and dirty decision — for example, via dot voting or by spending more time to get a more informed decision using the ICE matrix.
Don’t try to commit to too many action points at once. It’s better to deliver one next step and be half-done with five.
It might be tempting to wrap up the meeting once you have chosen the next steps. Don’t do it. The way you close the retrospective has a big impact on the whole team.
Retrospective closure has two primary purposes:
For example, to help the team retain critical information, you can ask everyone to state in one sentence their most important learning. You can also gather feedback on the retrospective using scoring and feedback systems.
If, at the end of a successful retrospective, you should have a clear answer to the following two questions:
Some might be surprised that the framework doesn’t include any review of the previous retrospective’s next steps. I believe this is an anti-pattern.
In a typical scenario, the team forgets about the retrospective next steps and you have to remind them after two weeks or so.
Strive to build a culture in which the team is always accountable for retrospective outcomes. Discuss them after daily standups or do weekly check-ins, whatever works for you.
Don’t turn a retrospective meeting into a status meeting.
“Five fully-fledged sections?! We don’t have time for that.”
It might be hard to imagine fitting all these steps into a 60- or 90-minute meeting, but it’s possible. The key is to timebox each section the same way you timebox the whole meeting.
These timeboxes won’t be perfect at the beginning, but eventually you’ll learn how much time you need for each section and will be able to plan accordingly.
If a lot is going on for the team, you can try splitting the retrospective. For example, you can have a separate meeting dedicated to gathering data and, a few days later, a separate meeting dedicated to generating insights, etc.
Sometimes having a few more focused meetings is more efficient than trying to achieve everything at once.
At the end of the day, there’s no perfect way to run a retrospective. Each team is different, each facilitator is different, and each challenge is different.
Take what works for you and leave out the rest.
The framework I presented might be a good starting point or a source of inspiration, but in the long run, you should experiment on your own to find the most efficient and engaging format.
Again, there’s no one-size-fits-all approach. So don’t be afraid to get creative.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
As the name alludes to, the way you frame a product significantly changes the way your audience receives it.
A Pareto chart combines a bar chart with a line chart to visually represent the Pareto Principle (80/20 rule).
Brad Ferringo talks about how he helped develop modern “earconography” — sound language that creates context-driven audio notifications.
Without a clear prioritization strategy, your team will struggle to tackle competing demands and can end up confused and misaligned.
Learn more →
