The daily standup, or daily scrum, is a short meeting the project team uses to briefly communicate work commitments with each other. Although used extensively by Scrum teams, the daily standup is not inherently agile. This quick meeting has been used extensively for years by agile software development teams, lean software development teams, kanban projects, the US military, and in many large and small manufacturing environments. Scrum teaches that all Scrum work sessions, or ceremonies, are timeboxed—that is, all work sessions must start on schedule and end on schedule, without exception.
In this article, I shall address some questions that agile teams, management, stakeholders, and those who are thinking about transitioning to agile methods commonly have about Scrum’s practice of holding daily standup meetings.
What is the value of holding the daily standup at the same place and time every workday?
Predictability is the most common reason. All team members are expected to attend. If a team member cannot attend in person, the absent member is expected to either attend by phone or have another team member communicate the absent member’s commitments. Though the standup will be held at the same time every day, consider allowing the team to choose the time if they are just starting out. However, keep in mind that the meeting may be more productive if held either early in the day, to prepare for the work ahead, or at the end, to discuss the day’s accomplishments and to plan for the next day. Where flex time is part of the company’s policy, the standup should be held either at the beginning or near the end of the “core” period. Where multiple time zones are involved, be considerate when choosing the time.
Why is it important that all team members attend the daily standup meeting?
The daily standup—also called the daily scrum, lowercase—provides value to the team and to the project. The origin of the term scrum came from rugby. During a rugby scrum, a team plans, bonds, executes, and recommits. For the standup, team members must be prompt because the ScrumMaster will start and facilitate the meeting at the appointed time, regardless of who is present. However, the overall conduct of the meeting belongs to the team.
Why is it important to timebox a meeting that is short to begin with?
Timeboxing produces predictability, and even if a person does not like to attend the meeting, that person should know that the annoyance is minimal and manageable. With small teams, the standup should last fifteen minutes or less. The reason the meeting is short and on a tight schedule is so that team members can quickly share what they have done since the last meeting, what they plan to do next, and identify any impediments and issues without wasting valuable time. Large teams that are challenged by complex architectures and perplexing technologies might require a longer standup session to share what they have completed and what they plan to do next.
What is so important about starting the daily standup on time?
If for no other reason, it is good manners, and not doing so is disrespectful to other team members. The ScrumMaster is expected to facilitate the standup meeting, and an important part of the facilitation is to ensure the standup starts and ends within the timebox. With new teams, the ScrumMaster starts the meeting by asking several questions to the person immediately to his or her left, proceeding clockwise around the room until everyone has responded:
- What have you done since the last standup meeting?
- What are you planning to do next?
- Do you have any impediments keeping you from performing your planned work?
- Do you have any major issues?
Although these are more questions than recommended in books, I prefer to ask them in this context because many people new to agile struggle with differentiating impediments and issues. An issue can be a situation that does not “impede” a person but can become a bottleneck if not removed.
New projects and new teams should not alter this approach before trying it first. Only after some time has passed and a team has become familiar with the Scrum process should a team consider changing the process by means of a retrospective.
Why must each team member answer these questions?
Questions relative to whether the team is meeting the goals of the sprint are the standard that ScrumMasters want team members to communicate to each other. Each member of the team should know about what other team members worked on and completed, what they plan to work on next according to what they have committed to do, any new or unresolved obstacles that may prevent achieving sprint goals, and issues that could become significant bottlenecks. During the standup, team members should not turn their responses into solutions, issues, problem-solving, or gossip when answering these questions. The ScrumMaster is responsible for moving the reporting along briskly from person to person.
Why aren’t team members allowed to expound their responses in detail during the meeting?
During the standup, only one person speaks at a time. That person is the one who is describing his or her situation with regards to committed sprint work. Everyone else listens. Side conversations are not allowed. Extraneous discussions tend to extend the duration of the meeting beyond the scheduled timebox. Larger teams may have to extend the timebox to ensure that all team members communicate their situations clearly and include any significant impediments they may have. For this reason, I do not recommend the use of larger teams; instead, large teams can be split into smaller, more productive teams.
What’s the big deal if someone chimes in to clarify a point or add to a team member’s response?
When a team member communicates something that is of interest to other team members, or if he or she needs the assistance of other team members, any team member can immediately arrange for all interested parties to get together to discuss the topic at length—after the standup. The ScrumMaster is key to this situation and is responsible for deferring further discussion by assuring that a follow-up meeting is scheduled immediately following the standup so that the topic will be discussed in detail.
Why can’t team members just start the discussion during the standup?
Discussions that do not focus on sprint goals deviate from the standup’s agenda and will exceed the timebox. As a courtesy, observers or attendees who are not team members should not talk, signal, make noise, make faces, or otherwise make their presence in the daily standup meeting obtrusive.
Why shouldn’t a little humor be allowed during the standup?
So long as the humor does not detract from the goals of the meeting—communication, commitment, and recommitment—a bit of tasteful humor is welcomed. However, observers or attendees must refrain from interfering with the meeting.
Some people have taken the position that anyone should be allowed to speak up during the meeting to ensure a specific point is made. What is the consequence of such behavior?
Disruption is the consequence. The standup is for the benefit of the team and, eventually, project management. Team members and observers who cannot or will not conform to the way the project team runs the standup meeting may be excluded from the meeting or removed from the team.
Isn’t this a harsh treatment of people who are trying to do their work?
To be treated as an adult, you are expected to behave as an adult, and that means good manners. Requiring good manners is not harsh behavior.
The Benefits of the Daily Standup
Project status meetings are typically conducted much too often, frequently holding team members hostage for hours that result in little or no value. On Scrum projects, the standup is conducted as a disciplined and controlled meeting with team members only, where everyone stands for a brief period of time to communicate their commitments and keep everyone focused and aligned with project goals. This results in less wasted time, better communication, and more value.
What are your experiences in making the standup a valued part of Scrum?
User Comments
Great article! It sounds like a Scrum Master needs to be a skilled facilitator.
While I agree to most of this article, I object to the "What have you done ...?" and "What are you planning to do ...?" part. I prefer the "What did you achieve ...?" and "What are you planning to accomplish ...?" questions, as they focus more on accomplishments (What changed? Which parts of the SW are new / improved?). With the "done" and "plan" notion, people too often justify how they spent their time, which is similar, but not the same. However, considering the human factor and the fact that the difference seems minor at first glance, this is almost impossible to enforce ...
How does a daily meeting jive with the intent to remove process? If anyone wants to know where things are look at the Kanban board and listen to what the contributor states as problem, then work towards removing that problem quickly.
If one needs a full time person called Scrum Master to manage the process then it is a clear sign that there is too much process. I rather have an additional developer or QA analyst than a professional host for yet another meeting.
Hi Tim,
Thank you for your comments on the article.
I believe you may have missed the point in your first statement. The daily standup is held so that all team members can communicate openly. The Kanban or task board must be viewable and modifiable so that any changes in what has been completed since the las standup is visable to all. Seldom are things clear when team members talk about what they have done. Often, there are extenuating circumstances behind what they have done and what they plan to do next. The last thing we want is to prevent people from meeting briefly face-to-face and talking.
Regarding your second statement, The Scrum Master role should not be performed by an unqualified person. He or she should be as knowledgeable as any developer on the team to enable clear and consise communication between all team members.
Scrum is facilitated by the Scrum Master who is accountable for removing impediments to enable the team to meet sprint goals and complete all planned work. The Scrum Master is NOT the team leader, but acts as a buffer between the team and any distractions, and assures the agreed-to Scrum rules are followed.
If your organization cannot provide such a person as Scrum Master, then your agile initiative may be at risk for failure. Your interpretation of the Scrum Master's role needs enlightenment. Recommend you read one of many publications available on Scrum, its activities, roles, and artifacts. There are hundreds and even thousands of Scrum articles that have been published over the last 20 years.