We started this series on the Scrum methodology with an introduction, followed by two pieces on two of the most important roles in the Scrum framework (the Scrum Master and the Product Owner, and an article on the framework itself and why it's called a framework for Agile working. Next up are the ceremonies or events around which a Scrum-based project tends to revolve.
When it comes to Scrum, a project consists of Sprints and Sprints are built up of events. The role which each of these events plays and the way in which they take place can differ considerably based on factors like the the product that is being developed, the experience of the people involved in the project, and the preferences of the team members themselves. In general though, in a traditional Scrum project, a Sprint contains at least four major events, namely Scrum planning (also known as Sprint planning), the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
After taking a deeper look at Scrum planning, the Daily Scrum, and the Scrum Review (also known as the Sprint Review) and its purpose within the Scrum framework. This article will focus on the Scrum Retrospective, which represents the final event of a Sprint in a Scrum-based project. A Scrum Retrospective usually takes place after the Sprint Review and the name already reveals what its purpose within the framework is, namely to provide a look back on the Sprint that has just been finished. The goal of this meeting is to find out which tasks or activities went well for the team, which tasks and activities should be continued, and in what ways the next Sprint can be improved. Scrum Retrospectives are basically improvement meetings that help the identification of pitfalls and past mistakes during the development process, in order to be able to better address and avoid them in the future.
Generally, these meetings are attended by all of the people involved in the Scrum-based project in question, from the Scrum Master and the members of the development team themselves to the Product Owner and possibly even the stakeholders. The keywords for Scrum Retrospectives are inspection and adaptation, as these meetings serve to inspect the most recent finished work and to adapt the development process if and where needed. By involving the complete team in this phase of the project, each aspect of the past Sprint can be discussed and everyone will be equally informed in regard to difficulties the team has dealt with. On top of that, having everyone present during these meetings also makes it a lot easier to communicate learnings and improvements for the next Sprint.
As with a majority of events that take place during a Scrum-based project, Scrum Retrospectives need to have a pre-determined duration. Of course, the length of such improvement meetings is influenced by a lot of factors, such as the size of the team, the experience of the team members, and whether some of the team members are located remotely. A general rule of thumb in this sense is that a Scrum Retrospective should take 45 minutes for every week of the Sprint concerned. That would mean, for example, that a 2-week Sprint would require a Scrum Retrospective of 90 minutes. Seeing as a Sprint usually has a length of maximum one month (four weeks), the maximum length for a Scrum Retrospective stands at about three hours.
As for most Scrum events, it's the Scrum Master's responsibility to make sure that all members of the Scrum team are present for the Scrum Retrospectives. As we said before, these are perfect opportunities for self-learning teams to improve its development process, and to practice making it more effective and enjoyable for all. If you want to be brief, you can describe a Scrum Retrospective as a meeting in which the team discusses what went well during the last Sprint and what can be improved during the next Sprint, but like this, the concept of these meetings might still remain abstract for some. That's why we figured it would be both interesting and helpful to take a closer look at how a typical Scrum Retrospective is organised in real life and what is required for it to be effective.
What would a typical Scrum Retrospective look like in practice?
Especially to those people who have not yet been part of a Scrum team or who have not yet been in contact with a Scrum-based project in another capacity, the concept of the Scrum Retrospective might still seem a bit abstract. When analysing the added value of Scrum Retrospectives to the Scrum framework, it's important to keep in mind how crucial communication and transparency are to the success of Scrum. Without pointing fingers at individuals, Scrum Retrospectives play a key role in keeping everyone informed and updated on the project's current status, and is basically the very first step in planning the next Sprint. In order to provide some insight into this process, we'll take a more in-depth look at what a Scrum Retrospective can look like in practice.
If you just open your internet browser and search for something like “Scrum Retrospective ideas” or even simply “Scrum Retrospectives”, chances are very high that you will immediately come across a whole lot of companies and individuals offering all kinds of original ways to mix up your Scrum Retrospective routine. Despite the fact that a Scrum Retrospective can come in countless different shapes though, based on important factors like the size and experience of the Scrum team in question, a Scrum Retrospective generally revolves around four main questions to be answered by all members on the team. Broadly speaking, these questions take on the following forms:
1. What went well during the Sprint?
2. What went wrong during the Sprint?
3. What was learned from the Sprint?
4. How can the next Sprint be improved?
In order to understand why these questions are asked to the team and what the value of the answers is, it's useful to look at and dissect each question individually. Structure is important for a fluent and effective Scrum Retrospective, after all.
What went well during the Sprint?
Whether a Sprint went well or not, it's always informative to analyse the most recently finished work. To start the Scrum Retrospective on a positive note, the team usually begins by discussing the things that went well during the last Sprint. After all, the best chance of repeating a success or even improving upon one is understanding the reasons behind it. During this first phase of the Scrum Retrospective, the team will attempt to identify its success stories, the skills, knowledge, and other strong points that contributed to them, and how the result was eventually achieved. This could be done, for example, by having team members write down positives on green Post-Its and sticking them on a whiteboard. Such an approach would promote transparency and hopefully encourage discussion amongst team members.
What went wrong during the Sprint?
After looking at what went well during the last Sprint, it's time for the team to look at the tasks and activities that went less well. It's extremely important to keep in mind at this point that this phase of the Scrum Retrospective was not designed to assess or penalise the performance of an individual, but as a way to gather information for the entire team. This information can then be used to solve or avoid the same mistakes during the next Sprint. Asking the team members about what they feel went wrong, why they feel it went wrong, and to what extent they feel they understand the problems in question can help reveal potential issues and difficulties for the project as a whole. As for the previous stage, a Scrum Master could have all team members write down issues on red Post-Its and stick them on a whiteboard. This would again lead to a more transparent manner of communication between all team members, with the goal being a more productive team effort during the next Sprint.
What was learned during the Sprint?
After identifying what went well and what went wrong during the last Sprint, and before moving onto what is basically the very first step in planning the next one, it's important for the Scrum team to go over what was learned. Not only does this help the team to go over all of its activities and tasks one more time, it also serves to check if everyone has gained the same knowledge about the project and the team's way of working. On top of that, it's also a good way to find out the quality of communication and cross-team understanding. By going over all of the learnings and checking if each team member has understood what was discussed, the Scrum Master can also get a better idea of the extent to which team members are aware of each other's issues while working on the project, which in turn is a good indicator of how closely the team is really working together.
How can the next Sprint be improved?
Finally, the last part of the Scrum Retrospective is about making the learnings of the last Sprint a part of the planning for the next Sprint. It focuses on how the coming sprint can be improved, based on the successes and failures of the Sprint that was just analysed by the team. That's also why (the ends of) Scrum Retrospectives are also considered to be the very beginning of a new Sprint cycle. By looking at where they currently stand, where they want to be at the end of the next Sprint, and how improvements to the development process can help them get there, the members of a Scrum team make it possible to constantly inspect, adapt, and improve the process, and therefore, the product value.
Organising the best possible Scrum Retrospectives
Hopefully you now have a bit better idea of what a Scrum Retrospective can look like in real life and what such a meeting consists of. Organising a fluent and effective Scrum Retrospective is not necessarily difficult, but still, it's a lot easier said than done. As far as the self-learning ability of a Scrum team goes, there are few events more important during a Scrum-based project than the Scrum Retrospectives. The team inspects itself and the work it has delivered, and uses what it learns to improve the next Sprint.
A badly organised Scrum Retrospective can also have deep negative effects on the project as a whole, though. It can happen that Scrum Retrospectives lose some or even all of their added value, because they are not implemented correctly at the end of a Sprint. This can have various reasons, such as the team members getting bored of the same meetings every time, the proposals for improvement not being implemented during the next Sprint, or when some or all of the members of the team are lacking motivation. Considering the importance of Scrum Retrospectives, we think that it could come in handy to place a few tips here below on how to organise the best possible Scrum Retrospective.
Make sure all of the team members feel comfortable
This might sound logical, but it's primordial for a Scrum team. During the Scrum Retrospectives, it's important for the team members to communicate with each other about what went well and what went wrong during the last Sprint. In order to do so in a constructive environment, these team members need to feel comfortable enough within the team to ask questions and voice concerns. The Scrum Retrospective should be something of a safe space for the people involved in the project. The Scrum Master can help team members feel more comfortable by fostering a relationship of openness. He or she can, for example, send friendly reminders for the upcoming Retrospective, accompanied with a summarised overview of the last Retrospective's results. Another good way to get everyone more comfortable is for the Scrum Master to start the meeting by answering the previously discussed questions him or herself. This way, he or she leads by example and encourages the team members to do the same.
In general, interactive exercises and games are a good way to break the ice, especially when not all the members of the team know each other very well yet. One of the most divisive issues that an occur in a team is the difference in expectations, which is why working on better aligning expectations usually has a positive long-term effect. It's important for team members to be able to express what the rest of the team can expect of him or her, and what he or she expects from the rest of the team. This can be done, for example, by giving each team member a piece of paper with three empty fields: one to write what team members can expect from him or her, one to write what he or she expects from the other team members, and one empty. Each person fills in the fields and passes the paper to the person next to them. That person reads what's on the paper, writes down their expectations of the author in the remaining empty field, and passes it on. Like this, the discussion can quickly and easily be focused on expectations amongst team members.
Be visual and clear with the team's results
One of the best ways to motivate a Scrum team is to regularly show them the progress they have been making, thanks to the framework. No matter if the improvements you made during the last Sprint were large or small, it's important that the team members are aware of them and of the impact overall. Even when it might not be possible to accomplish all the set goals, showing any kind of result should have a positive effect on the team's morale and their belief in the chosen approach.
Mix up the Scrum Retrospective routine a bit
Earlier, we described an example of a typical Scrum Retrospective based on a set of questions to be asked to the whole team. This was a simple example of quite a standard Scrum Retrospective routine that requires relatively little time if the team has a bit of experience. There are plenty of other ways to conduct these meetings though, and an often heard piece of advice is mix up the routine a bit every now and then. One of the major dangers to the added value of Scrum Retrospectives is a decreasing interest of the team members in participating in, or even attending, the meetings. Fortunately, there are plenty of tools and techniques available online to keep Scrum Retrospectives brief and interesting for everyone. Just check out websites like funretrospectives.com or retrospectivewiki.org, and you'll see what we mean. Don't be afraid to get inspired and mix it up a bit when dealing with a Scrum team.
Pick different locations
It's key for Scrum Retrospectives and other Scrum-related events to take place within an allotted amount of time in order to keep the workflow going, but no one said a Scrum Retrospective needs to take place at the office per se. As a matter of fact, for teams with a motivation issue when it comes to Scrum Retrospectives, changing the location of the meeting every now and then might do wonders. Why not hold the next Retrospective at the coffee bar on the corner? Or maybe in the park opposite the office? As long as it's a location that fits the whole team and allows them to focus on the Retrospective's questions and tasks without a problem, it doesn't matter a whole lot where it is.
Do a retrospective of the Scrum Retrospective
Sometimes, during a Scrum Retrospective, it's easy to focus completely on the Sprint that was just finished and to start planning the next one as quickly as possible. That's not always the best approach though, especially not for teams who have just started using the Scrum methodology or who have just begun working together. Quality control is key for the Scrum approach, which is why it takes place so frequently during a single Sprint. While a Scrum Retrospective can help a team control the quality of their work, it's also important to control the quality of the Retrospective itself. Therefore it's considered positive when team's don't only use the Scrum Retrospective to analyse the past Sprint, but also to inspect and possibly adapt the way of conducting the Retrospective in order to achieve better results when it's time for the next one.
Don't be afraid to rotate the meeting's facilitator
So far, we have spoken about the Scrum Master being in charge of the organisation and guidance of the Scrum Retrospectives, because that is generally the case. Nevertheless, it's not set in stone that the Scrum Master needs to take on this role, especially not when it concerns more experienced teams. As long as an experienced member of the team is comfortable taking charge of the Scrum Retrospective in question, he or she can plan and guide the meetings as well. Employing a rotation system in which the role of facilitator is rotated amongst the team members is also an additional way of challenging them. It forces them to look at the project from a different point of view from time to time and emphasises their importance to the project as a whole. Finally, rotating the facilitator role also helps to avoid one of the earlier points about the risk of the Scrum Retrospective routine becoming too repetitive and boring.