Let's first take a moment to reflect if your daily scrum should really be the topic of a sprint retrospective. If you’re not sure if you need to or what the indicators are, see how many of the following questions you answer "yes" to on the included checklist. You can also download the checklist here.
If you answered "no" to more than six questions, then it may be worthwhile to reflect on your daily scrum in a sprint retrospective. For this you can use the following format. The format is structured according to the 5 phases of a retrospective by Diana Larsen.
In thematic retrospectives, I always like to refer back to the theory behind the topic in order to make sure the principles of scrum are at the core of what we’re doing. It is important to me that the participants once again reflect on the theory behind scrum, i.e. once again visualize how scrum is actually intended to allow them to mentally detach from their daily work. At this point, I share the Scrum Guide and give the participants an opportunity to read it and refresh their knowledge.
The Scrum Guide describes the daily scrum as the opportunity for the team to inspect their progress toward the sprint goal. The inspection makes it possible to adapt the work or the sprint backlog as needed. Other aspects mentioned in the 2020 Scrum Guide include:
Focusing on progress toward the goal improves the team's self-management and focus.
For the next step, we need an assessment of the daily scrums by the team itself to understand what can be improved and what’s working.
In order to be able to collect this information in the most structured and comprehensive manner as possible, I build a list of statements about the daily scrum based on the Scrum Guide. Then I ask the participants to estimate how they perceive their daily scrum to the following statements. Each participant estimates these statements for themselves, based on two questions.
I like to list the following statements:
The questions I ask the participants about the above statements are as follows:
1) How do you think we are doing at this point in the scrum team?
2) Do you think we should change something?
Of course, you can also choose other statements.
Based on the assessment, you get an overview of how the participants perceive their daily scrum, which might be different in the scrum master’s view. With the feedback to the second question, you can see which topics the participants really want to work on to improve their way of working.
Afterward, you can evaluate the assessments together. For this I usually form pairs. During the evaluation, you draw the sum per assessment. Here is an example:
Then you sort out what you want to look at first. The indicator for this is a high assessment value for both questions. Now it is a matter of understanding this topic more precisely together. At this point, no solution ideas are to be worked out! If you already jump into the solution mode here, you could miss important details, which could lead to mistakenly only treating symptoms instead of getting to the root causes.
Solutioning ideas or ideas in general are great, there is only one problem: we almost always have too many of them. So at this point, it is important that you choose what to start with.
As a scrum master, it's important to pay special attention to the following:
Each participant now gets a number of votes, which is determined beforehand.
Afterward, evaluate the votes together as a team and discuss in detail how many solution ideas you want to implement. It is important to make sure that all participants jointly agree on how the solution idea will be implemented in the upcoming sprint.
Following the selection of your action, the closing of the retrospective now takes place. The objectives are:
The first thing I always do at this point is to thank the participants for their time and cooperation. Then, I briefly summarize what topics we have worked out and what the team agreed upon as actionable next steps. Before I move on to the second goal, I ask if anyone else would like to contribute or add anything. Only then do I move on to the second goal, the feedback on the process.
To get feedback on the process, you can ask one of the following questions, for example:
Either collect feedback verbally or written, when people leave the room.
For the participants the retrospective is now over. I would like to share a few thoughts with you, the scrum master.
Document the retrospective
Use the time directly after the retrospective to document it. Why? To have your observations and what you have worked out present later on. This way you can continue to work with it and don't forget half of it in as you go about your daily work. The documentation is done with a tool and in a scope of your choice. I usually use my scrum master journal and write down not only the results, but also my observations. I also like to use screenshots and photos of the results.
Furthermore, such documentation is also useful if not all invited participants were present. In this case, make sure that you inform the participants during the retrospective to share the results of the retro with team members who are not present.
What are the follow-up tasks for you?
Are there any tasks for you from the retrospective? I usually try to implement these immediately so that I can then close the issue. Even if it's sometimes just setting deadlines.
The daily scrum is the scrum event we use the most. It is our monitoring if we manage to reach the sprint goal. Therefore, it is only logical for me to pay attention to building a meaningful and value-adding daily scrum. However, it is often bogged down and not a real exchange; or worse, a status report. With the application of the retrospective format I described, I was able to help scrum teams optimize their daily scrum for themselves and feel comfortable with it. For example, we made adjustments to the questions in the daily scrum, rethought the place and time, or tried alternating formats in the daily scrum per sprint. As an example of this in a sprint, we kept the daily scrum silent at the start and everyone adjusted their tasks on the sprint backlog. Only then did we ask questions about them and talk about problems. In another sprint, we didn’t address the sprint backlog in the daily scrum itself and updated it outside of the daily scrum. Both formats led to more focus and a much more meaningful exchange in my teams. I hope this retro format helps you as well.
Want to know more about retrospectives? Check out the Scrum Alliance Learning Journey’s online course for members, How Successful Teams Practice Sprint Retrospectives. Designed for scrum masters, this members-only educational content explores ways to recognize common anti-patterns and improve the retrospective.
If you’re not a member, please learn more about the core competencies of scrum masters.
Get the latest resources from Scrum Alliance delivered straight to your inboxSubscribe