One of the core principles of agile is to inspect and adapt. The daily scrum is one of three critical inspect-and-adapt activities defined in the Scrum framework.
As you can see in the picture, the daily scrum happens (everyday) during sprint execution – after sprint planning and before the sprint review. (If you sign up for my newsletter, you can download a free copy of Chapter 2 of my Essential Scrum book that explains this picture in detail!).
The purpose of this posting is to define the daily scrum, elaborate important rules for conducting this meeting, and to clarify several misconceptions about the daily scrum that I encounter during my training and coaching engagements.
What is the Daily Scrum?
The daily scrum is a critical, daily inspect-and-adapt activity to help the development team achieve faster, more flexible flow towards the solution for satisfying the sprint goal. The daily scrum is a 15-minute, timeboxed activity that takes place once every 24 hours. It serves as an inspection, synchronization, and daily adaptive-planning activity that helps a self-organizing team do its job better.
The goal of the daily scrum is for people who are focused on meeting the sprint goal to get together and share the big picture of what is happening so that they can collectively examine what has recently been accomplished and to understand how much to work on, which items to start working on, and how to best organize the work among the team members. Examining the work in process allows team members to identify impediments that are affecting the flow of work and promotes quick decision making, ensuring continuous and useful progress towards meeting the sprint goal.
The previous description provides a concise overview of the daily scrum. In the rest of this posting, I want to define some rules for conducting the daily scrum and at the same time, address some common misconceptions regarding the daily scrum.
Daily Scrum or Daily Standup?
Let’s handle terminology first. Do you call it the daily scrum or the daily stand-up? Technically it is properly referred to as the daily scrum, but many people call it the daily stand-up due to the common practice of people standing up during the meeting. Standing is not required, but is often a good idea because it promotes brevity (and possibly better engagement).
So, although the terms are often used interchangeably, the correct term is the daily scrum. You have to admit, it would be wrong to call a meeting the daily stand-up if the people in the meeting were sitting down!
Is It a Status Meeting?
The daily scrum is not a traditional status meeting, especially the kind historically called by project managers so that they can get an update on the project’s status. A daily scrum, however, can be useful to communicate the status of sprint backlog items among the development team members. Mainly, as mentioned previously, the daily scrum is an inspection, synchronization, and daily adaptive-planning activity that helps a self-organizing team do its job better.
Who Should Attend (Pigs and Chickens)?
Scrum has used the terms “pigs” and “chickens” to distinguish who should participate during the daily scrum versus who simply observes. The farm animals were borrowed from an old joke (which has several variants): “In a ham-and-eggs breakfast, the chicken is involved, but the pig is committed.”
Obviously, the intent of using these terms in Scrum is to distinguish between those who are involved (the chickens) and those who are committed to achieving the sprint goal (the pigs). At the daily scrum, only the pigs should talk; the chickens, if any, should attend as observers.
I have found it most useful to consider everyone on the Scrum team a pig and anyone who isn’t, a chicken (as shown in the “better” part of the picture above). Not everyone agrees. For example, the product owner is not required to be at the daily scrum, so some consider him to be a chicken (the logic being, how can you be committed if you aren’t required to attend?). This seems wrong to me, because I can’t imagine how the product owner, as a member of the Scrum team, is any less committed to the outcome of a sprint than the development team. The metaphor of pigs and chickens breaks down if you try to apply it within a Scrum team (as depicted in the “confusing” part of the picture above).
Are the Three Questions Required?
A common approach to performing the daily scrum has the ScrumMaster facilitating and each development team member taking turns answering three questions for the benefit of the other team members:
- What did I accomplish since the last daily scrum?
- What do I plan to work on by the next daily scrum?
- What are the obstacles or impediments that are preventing me from making progress?
The vast majority of the Scrum teams that I encounter use this approach. However, this is just an approach—daily scrums don’t have to be conducted in this fashion. Other approaches do exist; if another approach works better for the development team members, then they should be free to use it.
Another approach, popular when using Kanban, is to take an item-flow focus and “walk the board.” The board in Scrum is the task board, which represents the evolving state of the sprint backlog over time (see picture below).
In this approach, the idea is to move the focus from the individual to the work items themselves (e.g., the user stories). The goal is to better understand how the work of each product backlog item is flowing (or not). The question the development team members are now collectively addressing is: “What do we need to do to move each item to completion?”
This approach is often called walking the board, since the flow of each item is shown by how the tasks associated with the item are progressing across the board. A common technique is to review the work (tasks) from right to left on the board. So, proceeding a user story at a time (presumably with the most important story discussed first) start the discussion with the tasks that are nearest to completion (on the right side of the board) and then move the discussion to the tasks in columns to the left that require discussion.
In contrast to the traditional three-questions approach, where each team member speaks in turn, in the item-flow-focus approach any and all team members can participate in the discussion of a single product backlog item. Some teams prefer this approach because it aligns the discussion around the flow of a given item, whereas in the traditional three-question approach, the discussion of a single item can be distributed in time based on when different people speak and could also be affected by the order in which people speak.
Should We Problem-Solve During the Daily Scrum?
The daily scrum is not a problem-solving activity. Rather, many teams decide to talk about problems after the daily scrum and do so with a small group of interested people. The problems (the impediments or blockers) can and should be raised during the daily scrum, but we don’t try to resolve them in the daily scrum since that is not the focus of the daily scrum. Additionally, everyone at the daily scrum may not need to be involved in the resolution of the problem—perhaps only a subset of the people is required. A common approach is for an appropriate subset of the team members to meet immediately after the daily scrum for detailed discussions to address the issue.
I once visited a client who told me its daily scrum meeting took two hours and that as a result, they only did the daily scrum every Tuesday and Thursday because of the time commitment! I quickly confirmed their daily scrums had turned into problem-solving meetings. Don’t perform detailed problem solving during the daily scrum.
Where Should the Daily Scrum Take Place?
There is no universal answer as to where the daily scrum should take place. If you have a team with distributed team members, then you need to answer this question about each location that has team members in it. Worst case, each team member is located in a different location (possibly their houses) in which case the answer to “where” is obvious—each person alone at home using some form of conferencing tool.
Let’s assume, however, that we have a concentration of people in one location. The obvious meeting location choices are in a meeting room or in the genba, a Japanese term that roughly translates into “the real place” or “where the work happens.” There could be appropriate reasons to choose a meeting room and many teams do. Personally I prefer to do the daily scrum in the genba.
Meeting in the genba has several characteristics that appeal to me. First, it reduces the overhead of trying to find an available meeting room. And unless your team has a dedicated meeting room, you might end up doing the daily scrum in different rooms on different days, which complicates logistics and could be confusing.
Apart from the logistics, I find it helpful to hold the daily scrum in the area in which the work is being performed. Doing so provides a known context for the team (helps trigger thoughts or reminders about the actual work). Even teams that use electronic tools to manage their artifacts often still have many items posted on the walls in their work area that can be helpful during a daily scrum. And, even if all work artifacts are stored electronically, there is often a large screen TV available for displaying relevant information (e.g., task board) in the work area.
When Should the Daily Scrum Take Place?
Now, when should you schedule your daily scrum? The obvious answer is the same time every day — and many teams can and do schedule this way. This approach has the benefit of it being simple. Hey, its 9:20 a.m., so it’s time for the daily scrum. It is a recurring event on everyone’s calendar. If we frequently changed the time of the meeting, then confusion sets in and absenteeism can increase.
Okay, so let’s say we do it the same time every day, when is the best time of day to do the meeting? Obviously that answer is very team dependent. I personally like the morning. I think a daily scrum is a great way to kick off the day and get everyone focused and synchronized on the work of the day. However, that approach might not work for your team. Perhaps you prefer it as an end-of-day activity—a great way to wrap things up and get synchronized on the big picture for the next day.
The reality in many organizations is they have members of the same team in different time zones. In these cases the daily scrum will not happen at the “same time” for everyone, although it can and should be at the same time for people in the same time zone.
The real issue with distributed team members occurs when team members are separated by many time zones (e.g., California to India is 12.5 to 13.5 time zones away depending on Daylight Saving Time). Such wide differences in time zones makes scheduling the daily scrum more difficult since the people in one time zone will be doing the meeting either very early or very late their time. Since we want everyone on the development team to be involved in the daily scrum, we will need to accept that certain team members will be inconvenienced.
A helpful strategy I have seen teams employ is called “share the pain.” The idea is to periodically (perhaps every couple of sprints) change the time of the daily scrum so neither time zone is always inconvenienced. For example, for a couple of sprints, we do the meeting first thing in the morning California time (making it past end of day in India). After a couple of sprints we reverse it and do the meeting so it is convenient to the folks in India and not so convenient to the people California (who are now participating in the evening California time). But by sharing the pain, at least everyone now feels like an equal citizen of the team!
In What Order Should People Speak?
As a final note, I occasionally get asked: “In what order should people speak during the daily scrum?” To be truthful, I don’t really care. To me this is an approach that team members should decide on. The order could be the same every day or change from day to day based on the circumstances. I’d be cautious about adopting the “best practice” of another team. If you want to read a funny story about this, have a look at my blog post “Context Matters: Why I Don’t Believe in Best Practices”. In particular, looking for the part about Tossing the Moose!
Conclusion
In this posting I defined the purpose and goal of the daily scrum meeting. I then pointed out the meeting is often referred to as the daily standup, but the proper name is daily scrum. Next I discussed how the daily scrum is not a traditional status meeting for the project manager, but rather a meeting for the development team members to coordinate their efforts toward meeting the sprint goal. I went on to discuss who should attend and addressed some confusion over the terms pigs and chickens. I discussed the common approach of using “the three questions” to perform this meeting and also discussed an item-flow-focused approach.
Next I discussed that problem solving should not take place during the daily scrum. I further discussed that the team can conduct the daily scrum wherever it wants, but I prefer to conduct the meeting in the team’s work area (the gemba). Then I discussed when the meeting should take place and addressed how this could be affected by having distributed teams. I ended by recommending that team members decide in which order people should speak at the daily scrum and that they should not feel compelled to use the same approach as other teams.
So what do you think? Do you conduct your daily scrums this way? Do you have different rules or approaches? Leave your comments below?