I’ve had the opportunity to conduct well over a thousand daily scrums over the past 8 years, with different teams in different environments—and it’s been an eye-opening experience. Conceptually, a “daily scrum” is quite simple; in the scrum vernacular, it’s a 15 minute status meeting where each member of the team answers the following three questions:
- What did I do yesterday?
- What will I do today?
- Do I have any impediments in my way?
In practice, I’ve found the daily scrum often has a slightly different “feel” from team to team. What works with one team sometimes goes awry with another team; and teams with different habits, environments, and personalities present new challenges to what seems like a simple process. Over the years, I’ve found that small details matter, and while adjustments may need to be made, they make a measurable difference in how the team responds. Here are a few of my observations and “lessons learned”:
Keep it short and keep it standing.
Since most conference rooms have chairs, my early experience with daily scrums is that everyone would sit down for the meeting. This was a bad idea. Making ourselves comfortable was a prescription for dragging things out—after all once you’re sitting down, you don’t really feel like immediately getting back up, do you? After finding that our scrums were lasting 20-30 minutes, we tried changing our approach to standing only, and the difference was dramatic. The pace naturally quickened; we covered the same amount of information but in nearly half the time, as comments, almost by magic, were kept focused and to the point. Whatever the psychological/biological reason this happens—keeping it a “standing meeting” works.
If you’re still not able to hit 15 minutes, even with great focus, you may have too many people in the room at one time. The “ideal” team size for a Scrum team is considered 5-9 people; if you have appreciably more than that you might consider splitting up the team and the scrums. The longer the meeting the less engaged your team will be; those at the front of the line will tune out and want to get back to work as soon as their turn is over; while those at the back of the line will tune out and distract themselves with their laptops or smartphones until their turn finally comes around. You want to avoid this at all costs. 15 minutes is not an arbitrary number but a benchmark for a meeting for which our attention span will last, and that energizes instead of depletes.
Leave judgments at the door.
An important principle is that the daily scrum is meant to be a reporting meeting, not one in which judgments are to be offered or implied. In other words, no one should ever show up to the daily scrum afraid to report their status, for fear of being judged in the meeting. If the team is concerned about a team member’s particular status, this should be discussed outside of the daily scrum. During or after a team member reports their status in the daily scrum, there should not be any judgmental reactions from anyone else on the team, ScrumMaster and Product Owner included. This is critical to protecting the integrity and the transparency of the reporting process; neither accusatory nor defensive behavior belongs in the daily scrum—period. This especially applies to stakeholders, even if they’re just “popping into” a random meeting—which bring us to the next point.
Stakeholders can attend, but only team members can talk.
Stakeholders outside the team may like to attend the daily scrum to “see how things are going”, but this is not the time for them to talk about their concerns. In one of the worst daily scrums I can remember, a team member was reporting that a certain task was taking much longer than expected. Overhearing this, a stakeholder interrupted to express his outrage and incredulity over what should have been, in his opinion, a “simple task”. What followed was a very heated argument—one that nearly ended in fisticuffs! Fortunately things cooled down, all sides apologized, and the stakeholder realized his mistake. The moral of the story is to remember that the daily scrum is meant to be a meeting for the team to safely and effectively report their progress and issues—not for attendees to have arguments and discussions about the results. Those should all be handled outside of the scrum (preferably in a civil manner!)
Use a task board.
I initially started doing daily scrums just by going around the room and asking everyone the “three questions”. I should explain that our firm was a fast paced, multi-project environment—so it will sound better when I tell you that almost no one could accurately remember what they did yesterday or what they were supposed to work on next! I consequently started using a Scrum task board and have found it to be indispensable ever since.
Scrum task boards do not have to complicated. They simply needs to list all the tasks the team is working on in the current iteration, who is the point person for each task, what the status of each task is (Not started/in progress/done/impeded, etc.), and preferably, an estimate of the remaining time on the task, updated at each daily scrum. If you can find software that does all this, that’s fine, otherwise you may be better off just using a spreadsheet or writing it on a whiteboard. The task board is meant to be a tool that facilitates the daily scrum, not something that has to be managed and conformed to (something to consider before you invest in an expensive or complicated product).
My preferred approach is to sort the task board by name; this provides an order with which to call on team members. Establishing a rationale like this helps so that people don’t feel that the order they’re called on is unfair or biased. When it’s each team member’s turn to talk, they can refer back to the task board for both their in-progress items and “to-do” items; this facilitates the flow of the daily scrum so that don’t have to spend time jogging their memory.
Finally, tracking estimates on the task board is useful for a number of reasons. First, it forces people to get better at estimating; initially the team may be hesitant to estimate items on the task board, but with repeated practice, they will improve their estimating skill. Second, updating the “remaining time” on a daily basis can be very illuminating. When remaining tasks hours don’t burn down, or actually go up instead of down, this is immediate feedback that something was underestimated—and you can make adjustments before you run over-time and over-budget.
It is for this reason that keeping a burndown chart for the task board is also valuable—so you can project, not monthly, or weekly, but daily, how likely you are to complete the tasks in an iteration. This is extremely valuable for projects where time is short, and this level of monitoring and projection is a necessity.
When possible, I prefer to break down tasks into chunks that are no larger than a day’s worth of work. Why? This is so that every day, each team member has the potential to strike at least one task off the task board. This makes the daily scrum a much more fun and satisfying experience for all involved, and builds a sense of momentum for the team.
Don’t forget that the ScrumMaster and Product Owner are also part of the team.
Often we assume that just the “developers” should be reporting in the daily scrum, but in reality, sometimes the Product Owner or ScrumMaster have tasks they need to do for the team.
The ScrumMaster’s job is to remove impediments; they may have tasks that include doing research, arranging necessary meetings, troubleshooting or escalating issues, or doing other support work.
The Product Owner has to make decisions and give approvals; to do so they may need to consult with others, review data, perform user-testing, or document new details or requirements.
When such tasks arise, I like to define them and add them to the task board. What better way to make certain they don’t slip through the cracks? What better way to make certain—with attention focused on them via the daily scrum—that they get accomplished in a timely manner? What better way to bring the team together than to demonstrate that everyone is being held to the same level of accountability? This is part and parcel of what makes Scrum effective.
Consider these two other questions.
In theory, the daily scrum is supposed to be focused on the “three questions” with which I began this article. In practice, however, I have sometimes found it valuable to elicit just a little more information from a team member based on their report. This is information, I, as either the ScrumMaster or Product Owner for the project, can use to do my job more effectively. These additional questions, discretionary in nature, are:
- What additional conversations does the team need to have?
- What needs escalation, and what are the underlying issues?
This is where the importance of listening comes in. It could be a small detail a team member mentions in passing, or the way they say something—which necessitates probing a little deeper—and discovering something significant which was overlooked, unanticipated, or requires additional work, planning, or discovery. This is often where one can find the greatest benefit of having a daily scrum. Using the daily scrum to encourage good communication is not at all a bad thing—use this time to make sure any important issues are raised to the surface so they can be addressed.
Branch off side conversations.
On the heels of the last point, when issues are identified as needing further conversation, have those conversations outside the daily scrum. To go into any depth on a side conversation derails the momentum of the meeting, causes it go over 15 minutes, and wastes the time of people who are not directly involved. A balance needs to be struck between allowing some helpful conversation but then cutting it off to be continued “offline”. This approach allows relevant dialogue to get started at the daily scrum, but without it taking over and overriding the purpose and intent of the meeting.
It’s OK to have fun.
If you enforce certain things, like always starting the daily scrum on time, keeping it focused, and keeping to the time limit (15 minutes), then it’s OK to let the team have a little fun. You’ll be doing a LOT of daily scrums, so it might as well not be a somber, dreary affair. It’s not unusual for a joke or two to be cracked during our daily scrums, and a little smiling and laughing is certainly a good way to start the day. If you have your other rules in place, it should never pose a problem to make your daily scrum an enjoyable experience that the team looks forward to.