How to Run a Sprint Retrospective: The Essential Guide

Many agile leaders agree that sprint retrospectives are considered a continuous improvement opportunity for a Scrum team to review the good, the bad—and the ugly. But, there are also team members that waver the idea of sprint retrospectives at the end of every sprint. In this blog post, I'll discuss why Sprint Retrospectives are important for a successful agile project and share some ideas to go from boring to booming.

Let's start from the beginning, shall we?

You may also like: Sprint Retrospectives With Kanban

What Is a Sprint Retrospective?

Sprint retrospectives usually happen after the Sprint Review and before the next Sprint Planning. They help a Scrum team review its process and identify opportunities to improve it.

As defined by The Scrum Guide, developed and sustained by Scrum creators Ken Schwaber and Jeff Sutherland, the purpose of the sprint 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 to improve the way the Scrum team does its work.

Now, The Scrum Guide is definitely the best and most complete guide you will ever need to learn Scrum the right way. No disagreement on that.

However, putting the theory aside, I know by experience that Sprint Retrospective meetings tend to be avoided by the Scrum team. And that's not because they don't know the benefits these sessions provide. It's simply because they know how tedious they can be if not led with creativity and energy from the project or engagement manager.

Therefore, the question now is: how can you successfully implement Sprint Retrospectives in your projects while making these sessions a powerful and enlightening experience?

Challenges Ahead of a Sprint Retrospective

Sprint Retrospectives are a golden opportunity for your team to express themselves. It's imperative that we learn how to listen to them. They are the primary "indicators" of the success of the project delivery. A well done agile retrospective boils down to great benefits, including a more self-organized team, better collaboration, faster velocity, and happier end-users.

However, when it's time to schedule a Retrospective meeting, project managers and development teams are hesitant, especially if they're already a few sprints ahead. Sometimes teams get bored when they don't see changes or actions being taken based on past retrospectives. Other times, the team lacks the motivation to fully express the way they truly feel about how the project is coming along.

In fact, I've seen leaders decide not to do Sprint Retrospectives at all due to the time it takes away from app development.

"That's boring as hell! It doesn't add value to the team, and it takes at least one hour of the time that my developers could use to program. It's just a session to tap people on the back to increase their egos on how awesome they've been!"

I do get their point though: analyzing past events can get repetitive sometimes, leading to a lack of creative ideas and dulled critical thinking for areas of improvement. Especially with bigger projects where sometimes we find ourselves in the tenth sprint and have no idea of what to say in the next retro meeting. "What a waste of time", you may think. But, is it?

The Value of a Sprint Retrospective

Through my experience as an Engagement Manager at OutSystems, I've discovered that many agile leaders, including myself, in the beginning, don't understand the true value of Sprint Retrospectives.

These sessions are indeed a great opportunity to appreciate everyone's contribution to the project. But they are also great to identify what puzzles people, what they want to improve, and what has become a risk to the project scope, timeline, or budget. At the end of a Retrospective, everyone involved should decide on the action items that should be taken to improve future sprints.

Therefore, it's now time to throw your retrospective word document template away and break free from the barriers of boring retrospective analysis strategies.

Sprint Retrospective Ideas: Tips for an Effective Meeting

Before I share the template I use in my scrum retrospectives, I'd like to introduce the questions that are the foundation of its structure.

Sprint Retrospective Questions

During the Sprint Retrospective, your team should discuss four main questions:

1. What did you like in the sprint?
2. What's still puzzling you?
3. What didn't work well?
4. What are your improvement ideas?

These questions will guide your sprint retrospective agenda and help your team decide on the actions to improve the next sprint. Now, as promised, let's move to the template that you can use to make your next meeting a booming success.

Sprint Retrospective Template

Sameer Bendre, a colleague of mine at OutSystems, introduced me to the following approach. He adapted the game called "Actions for Retrospectives" created by Innovation Games to brilliantly create this approach. You may find out more about Sameer in his blog post "For All My Life I'll Feel It: Lack of Empathy Kills User Adoption".

Here's a step-by-step on how it works.

1. Create the Grid With the Four Questions

Start by drawing a large 2×2 matrix with a square called "Actions" in the middle. This square is where you'll add the changes that your team commits to embrace as a result of the retrospective. The other squares represent the questions I've just shared:

 Appreciations: What Did You Like During the Previous Iteration?

This is the moment to thank all the effort your team has put into the last sprint and make sure they get the credit they deserve.

This way, you'll encourage them to continue doing a great job and ensure they are happy doing it.

 Puzzles: What Is Puzzling You Right Now?

In this category, you give your team the chance to ask for clarification on the things they're not sure about. This could be about people's role, technical or functional processes.

People are afraid of things they are not sure about, and this section helps us remove the uncertainty shadow out of the game and release that fear.

 Risks: What Didn't Work so Well?

These "risks" might be something really serious that puts the whole project in danger and, thus, they need urgent attention. But it could also be something more specific that it's making someone uncomfortable and probably preventing that person from doing the best possible job.

The goal of this section is to let your team express their feelings and not keep that "bomb" with them. Together, the team can find the best solution and make sure the project is truly successful.

 Wishes: What Are Your Improvement Ideas?

In this category, you give your team the chance to share that secret idea they've been keeping for themselves. Some extra questions you can ask are: what suggestions do you have to make this project even greater? What do you think we may be doing wrong that can be addressed in a better way and improve our current processes? As leaders, we are experienced but we don't have all the answers. So, who better than the people in the field to identify improvement opportunities?

2. Fill the Board With Sticky Notes and Start the Discussion

The whole team should write their suggestions and concerns for each category on sticky notes. It doesn't have to be a detailed description explaining the whole idea. The initials (so that we know who the author is) and a simple phrase (so that we can refer to it later) will do.

Every time that someone writes an idea, post the sticky note onto the chart in its corresponding section, as described above. This should take five to ten minutes at the most, depending on how many people you have in your team.

Once everyone finishes writing their ideas, we should discuss each sticky note so that everyone gets a chance to better explain their ideas. As a team, we should then discuss the novelty, feasibility, and impact of the ideas, and collaborate to analyze how they can be applied to improve our next iteration.

3. Vote on the Best Ideas

After we cover all the sticky notes, comes the voting time.

Before proceeding with any action, we should focus on creating specific action items so that our next sprint goal can be accomplished. Therefore, each team member should vote on the three sticky notes that they think we must take action upon.

4. Define Next Action Items

Then, we should create practical and efficient "actions." This should be posted in the middle section of the chart, and assign a person responsible for each action item. Remember that the key is to vote on the cards with the actions that we think we should proceed with.

This is a great strategy to fully and comprehensively reflect on the past and move towards the future. It involves extensive teamwork and dynamism so our team can think about retrospectives as a session to brainstorm changes for progress.

Also, by writing thoughts down and working together, participants will be more comfortable providing ideas for how to improve the Sprint rather than feeling as if they are criticizing past ideas.

Finally, remember that people may forget about these action items after the Retro is over. My final tip to add action items as tasks to the Sprint Backlog, and include them in your Daily Stand-ups.

Conclusion

Sprint Retrospectives can help you motivate your team by providing them the opportunity to speak up, share their ideas, and be heard. Perhaps they wouldn't share using the classic good/better approach, and you’d be losing a lot of great ideas.

In my case, I work with a low-code platform, which means my team develops user stories 3 to 4 times faster than with traditional programming languages. This makes each 2-week sprints a whole new world of possibilities. If feedback isn't taken on time, we risk lagging behind the game pretty soon. I discovered that pretty soon when my first developers were complaining that they didn't have enough "fuel" to go on in a sprint.

Thank you and happy Retros!

Further Reading

The Four Questions of a Retrospective and Why They Work

How to Use Data to Improve Your Sprint Retrospectives

Agile Retrospective: The What, Why, and How (Quick Guide)