As we continue talking about the 5 meetings of Scrum, today is the time to discuss the sprint retrospective meeting held at the very end of the sprint.
We will look into the meetings’ format, purpose, and its’ part in the Scrum framework in general. Last time we covered sprint review, so if you’d like to learn about it too, read our recent blog post.
What is a sprint retrospective?
Continuous improvement is in Scrum methodology’s DNA, and sprint retrospective meetings are one of the key facilitators of the improvement and learning.
Sprint retrospectives happen on the last day of the sprint with the main goal of reviewing the sprint, discussing various aspects of the process that was implemented, and preparing for the next sprint.
The timing of the meeting is crucial because, by the time the sprint is ending, ideas and thoughts are still fresh and at the top of the team’s mind. That’s when it is the best time to act on them.
It should always occur after the sprint review and before the next sprint planning meeting.
Please note that sprint review and sprint retrospective are not the same! During the sprint review, the team presents and discusses the results of the sprint – the product increment that they produced. In a retrospective meeting, the team looks back at the sprint and identifies ways to improve the next sprint.
The sprint retrospective format and purpose
The meeting is time-boxed and recommended to stay within 2 hours for a one-month sprint, or 1 hour for a two-week sprint.
However, the length would depend on:
- The size of the Scrum team. Discussions with more people take proportionally more time, although the methodology’s best practices suggest keeping the teams under 9 people.
- How well aware of all processes and sprint steps Scrum team members are. If the team is new, they might need more time to figure out certain subjects and nuances. If part of the team is remote, it is also recommended to reserve more time for the meeting. In-person teams should avoid prolonging the ceremony beyond standard length.
Sprint retrospectives are attended by the product owner, the development team, and Scrum Master. The development team is synonymous with the Scrum team or Agile team, and it includes anyone who is involved in the creation of the product increment.
Every member of the team needs to attend because they each work on various tasks and have a different perspective. Everyone is equal and everyone’s input is valuable.
Scrum Master acts as a neutral third party facilitates discussions, makes sure the teams follow the Scrum principles and guides them whenever necessary. Yet, he doesn’t necessarily run a sprint retrospective. The meeting resembles a guided discussion, rather than a formal agenda-based session.
The sprint retrospective is a team-focused meeting, so stakeholders are discouraged from attending. Instead, they should participate in the sprint review.
The 3 questions of sprint retrospective
The sprint retrospective is all about gathering data: what happened, what did you see, what can we learn.
The 3 important questions of the meeting are:
- What did the team do well?
- What didn’t go well?
- What can be improved?
Every retrospective meeting is slightly different but the common exercise that teams do is going one by one, each person responding to those 3 questions, followed by a group discussion of each point.
An alternative take on the 3 core questions is the start-stop-continue format. Basically, each team member shares their opinion on:
- What the team should start doing.
- What the team should stop doing.
- What the team should continue doing.
It is best to let the core team decide what kind of format and phrasing works best for them. There are lots of sprint retrospective examples online that you can browse for inspiration and experiments.
What is discussed in sprint retrospectives?
The sprint retrospective is one of the significant events in the Scrum project management framework.
It is the time to generate insights, gather data, remember past events, create a positive change, and come up with creative ideas. Let’s look into Agile retrospectives’ discussion topics in more detail:
What went well during the last sprint cycle and how the good parts can be replicated in the future. The project team identifies what skills or knowledge helped, what kind of motivation prevailed if a particular team member provided the best help or insight to the process.
What went wrong during the last sprint. It is important to note that there is no place for the blame game. Everyone is equally responsible for good and bad things, so the team reflects and simply acknowledges any downfalls that occurred.
How can we avoid repeating our mistakes? At what point did things start to go downhill? What stopped us from identifying and eliminating the negative trend right away? As a logical continuation of the previous point, we identify our mistakes and work on fixing them, instead of drowning in self-pity.
What can be improved moving forward: preventive and corrective measures, duplicating the success. How can we optimize our work with sprint backlog? Basically, how can we ensure that future sprints will be a bigger success?
Looking at processes, tools, relationships, teammates. How did everything and everyone cope with the sprint? It is also a good place to discuss other Scrum elements, e.g. artifacts, other meetings, tools that were used, or even minor things like sticky notes with user stories on the wall.
Definitions of done can also be reviewed and adapted. For example, the team becomes more qualified and increases their quality standards, making the previous definition of done redundant.
Anything and everything is up for discussion. Scrum is flexible, and teams can make it their own. The process should never be more important than people, so if something doesn’t work it needs to be changed or discontinued.
While it is up for a debate, we identify the core purposes of sprint retrospectives as:
- Continuous improvement of the whole team.
- Make sure there is a quiet time to reflect on what just happened during the sprint and plan to implement changes before the next sprint starts.
Theoretically, any time is a good time for reflection and learning. However, as we all know, things tend to get hectic and self-improvement activities often get pushed down the priority list and never happen. Sprint retrospective makes sure there is a dedicated time and place for such core Scrum activities.
Making your sprint retrospectives a success
To have a successful retrospective meeting, the teams have to apply the lessons they learned during the sprint and discuss them over the meeting. Improvement takes effort and energy, so it’s not enough to just talk it over and hope for the best. Every team decides on how they ensure the learning and changing happens. If you are not sure how to arrange that, an Agile coach would be the best person to reach out to for help.
As you conduct a few of the sprint retrospective meetings, you will get a feel for what works best and how you should plan and structure it. However, there are some recommendations that generally work for everyone:
Keep it simple. Don’t overcomplicate or over-formalize the ceremony. It’s fine if not everyone has answered the three questions if the conversation is flowing and the discussion is healthy and active.
When team members are discussing something, ask them to be more specific and share actionable feedback that can be implemented. The “it is not working” argument is fine if it’s followed by something more tangible.
Make sure every sprint retrospective meeting ends with a summary of all key points. It’s great to have a passionate discussion but it needs to lead somewhere. So, in order to truly follow the Scrum values, get a list with key ideas that will be followed up once the retrospective session is over.
Avoiding the common issues
Here are the 4 tips to avoid common issues during the sprint retrospective meeting:
Encourage the team to write down their thoughts and suggestions right when they have them. It’s much more productive for the team to list sprint retrospective ideas when they come up. Otherwise, you will have a group of people that sit in the meeting with blank faces or desperately try to come up with anything decent they could share or suggest. We want the ideas to flow organically and not stress anyone out.
Agile meetings should be a negativity-free zone. Judgment and negativity are normal emotions and it is okay to express them in general, but not during the sprint retrospective. Before the meeting, set expectations and make sure to communicate the ground rules: hostility is unacceptable.
Scrum Master or the product owner can meditate whenever necessary, keep the discussion positive, and do the general retrospective facilitation. It is important to monitor those things and not let someone’s toxicity ruin the experience for everyone.
Make sure the same ideas and feedback are not dragged from past retrospectives to the next ones. It’s understandable that not everything goes perfect and some issues or improvements take longer than one sprint to be worked through.
However, if 9 out of 10 things migrate from the previous retrospective onto the next sprint retrospective ceremonies, you might have a problem. Not only does it signal that the necessary change and continuous improvement are not really working, but it can also discourage the team and demotivate them even further. So, if you notice that trend, review it with the project manager and Scrum Master and see how you can mix things up and move away from this pattern.
Get leadership on board to support changes and improvement. Sometimes the team starts to highlight opportunities and necessary changes that are outside of the project team’s control. And if the company has not yet fully adopted Agile and Scrum, there might be issues with making changes that affect other people.
It takes a lot of diplomatic skills and patience, but the product owner or the project management team should take the time to communicate the values and goals of methodology, and make everyone in the company an ally. Obviously, it’s better to do this before the project launches, but the second-best time is now.
The benefits of running a sprint retrospective
If you are still not convinced that sprint retrospectives are an absolute must, here is the list of benefits that can change your mind:
- It is a place where opinions can be heard.
- It is a safe space to share feedback.
- It helps the team mature and get better.
- It highlights the best ideas for the upcoming sprint.
- It ensures small changes are identified and acted upon.
- It allows one to not miss an opportunity.
- It helps leave the bad practices and experiences behind.
Sprint retrospective enables the team to learn and improve, leading to higher effectiveness and high-quality results.
The key goal is to point out and implement immediately all new practices and processes that make the sprint process better. Similarly, any negative experiences and failing initiatives have to be reviewed and corrected or discontinued before moving on to the next sprint.
Scrum supports and encourages improvement at any point of the sprint and project as a whole. However, there is not always time and a place for it. That’s why you should run a sprint retrospective and make it a dedicated safe space where the teams get to inspect, review, and adapt anything they’d like.