The daily scrum is probably the simplest of all the scrum ceremonies to hold, but perhaps the hardest from which to get the most value. During this event, you are looking to answer three simple but crucial questions:
What did you do yesterday?
What are you doing today?
Do you have any roadblocks?
The mechanics might seem simple on the surface, but depending on the type of update the team provides, you could end up with a Goldilocks effect: A team member who shares too little in the update, one who shares too much information and one (hopefully the majority of the team) whose update is just right.
the goldilocks effect
Here’s how the Goldilocks effect might look in a scrum meeting:
At one end of the Goldilocks spectrum is the team member who will zip past their update without providing any context on their progress. Consider the following update:
Yesterday I worked on the login screen. I’m still working on that today. I don’t have any roadblocks.
At first glance, this might sound like a good update. The danger of this, however, is that the team might be quick to move on and miss the fact that the team member gave very little context as to where they stand on the sprint. Because of the brevity of their update, the team does not know if part of the plan was to begin on something else today and the team member is within the margin of being able to absorb the change in their plan. The team member might or might not be aware of being blocked, and there might be several reasons as to why they might not be comfortable to go into detail as to why they are blocked.
At the other end of the spectrum is the team member who provides more information than needed, turning the touchpoint into a different kind of meeting. Consider the following update:
Yesterday I worked on the login screen. Oh, by the way, Roger, I made a small change to the design you gave me because I ran into some issues with responsive design. I don’t know why this is happening—has anybody else run into this before? Maybe you and I need to get together to make sure you are still OK with it. Oh, today I am wrapping up the login screen and moving on to the back-end work. This ended up being more complex in some respects and I had to do some rework to minimize the technical debt I would end up with. Hey Sally, did I ever get a contract from your API endpoint? I didn’t see it in the story and I could not find it in Teams. I don’t have any roadblocks other than having issues building and for some reason, it sporadically takes way too long to build. Has anybody experienced this before?
This update is on the too much side of the spectrum because there is way more context than needed and some of it is even not relevant to the entire team. In a couple of cases, the update might have even turned into a one-on-one conversation between the different team members with everybody else taken along for the ride. This team member has valuable points that need to be addressed, but they have missed the intent of the update and turned it into a status meeting.
In the healthy middle—and hopefully, this is most of your team—is the team member who provides just the right amount of information. Consider their update:
Yesterday I worked on the login screen and finished it as planned. Today I am working on the back-end integration. Roger and Sally, can I talk to you about a couple of things after the scrum, please? I have a couple of quick questions to ask. I don’t have any roadblocks.
This update does not only answer the three questions in a precise and concise manner but also lets the rest of the team know that the team member is on time and things are going as planned. This is important because had the team member said they had not finished the task from yesterday as planned but were finishing it today instead, it would allow the scrum master to potentially step in and confirm they, in fact, did not have a roadblock. In the presence of a roadblock, someone with bandwidth could take on some of the work and allow the team member to finish on time.
four easy changes to promote effectiveness
But how do we help those who gravitate toward the ends of the Goldilocks spectrum? I have found that making four easy changes gets those who need help on track.
1. Display the Sprint Board
Depending on the size of the project, chances are your team is using Azure DevOps, Jira, or a similar tool to manage your project. These tools have a sprint board that shows all the assigned work at the task level. Displaying the board while people give their update helps them stay on point and remember the specific work that is in their In-Progress column.
2. Display the Three Questions
I have found that this is a very helpful way to remind the team that the questions are the outline of their update. Even the most mature teams that have internalized the why behind the daily scrum can fall in the trap of the two extremes. Having the three questions for the team helps everyone stay on track.
3. Prevent Monologuing
This is perhaps the hardest thing to do because it involves interrupting someone while giving their update. This obviously must be previously discussed with the team. An excellent time to bring up opportunity for improvements around the daily scrums is during a retrospective. This is where you can point to the behavior without singling anybody out while at the same time ask for permission to politely interrupt to get someone on track. With the team’s buy-in, you are now able to get the conversation back on track when needed. When confronted with a too much update, the scrum master can intervene by saying:
I’m sorry to interrupt you, Mark, do you need Roger and Sally to stay behind after the scrum? We can then discuss the changes to the design and get confirmation from Sally on the API endpoints you need.
This keeps the flow of the meeting going while addressing the needs of the team member with questions. It also coaches the team into the just right type of update where they themselves ask for other team member’s time.
4. Name the Task
Have the team specifically refer to a task while giving their update. Consider the following change to the just-right update:
Yesterday I worked on task 1234, which deals with the login screen, and finished it as planned. Today I am working on task 1235, which deals with the back-end integration. Roger and Sally, can I talk to you about a couple of things after the scrum, please? I have a couple of quick questions to ask. I don’t have any roadblocks.
This update gives context around what the roadblock is, but also allows everyone to follow the update while looking at the board. This would also allow the scrum master to confirm that what they need from Sally does not become a roadblock. It also allows anyone who wants to stay behind to do so without being forced to hear a conversation that might not pertain to them.
moving toward better daily scrums
I have found these tips to be easy to implement, low-hanging-fruit improvements to turn less than effective daily scrums into what they are intended to be: a daily touchpoint that allows everyone to take the heartbeat of the team while providing help to those who need it.
Do you have other tips for better daily scrums? I would love to hear your thoughts. If you’d like to talk about effective agile and DevOps transformations please reach out to us firstname.lastname@example.org.