Scrum Rituals: Daily Standup

Traditionally, the daily standup is limited to 15 minutes. It’s a short ritual, and it’s kept short and made as convenient as possible so that everyone can commit to being present, participating actively, and paying attention while other people are speaking. Everyone is expected to stand, both so that they pay attention, and to encourage all participants to play their part in keeping the ritual short and focused. Most teams try to hold the standup away from their desks, and discourage people from using laptops and other devices during the ritual.

Different teams will choose different times of day to hold the stand up. Often first thing in the morning, or right before lunch, can be good times. These are natural breaks in the day that are usually common to most people on the team, so a 15 minute standup won’t disrupt the focus needed for longer blocks of programming time.

Finding a time that works for everybody can be challenging for teams that aren’t co-located, especially when some members of the team are in different time zones. Nobody should be allowed to miss the standup on a regular basis, but there’s always room for flexibility, as long as the objectives of the daily standup are being met. Even if not everybody can make it to a specific standup, the scrum master should keep the ritual for anyone who is there.

Sometimes teams may need to come up with their own systems, and iterate on these reflectively from sprint to sprint. The priority should be on keeping the rituals brief, maintaining them reliably, and making sure they provide the intended value without creating undue interruption.

Every team member should be present and available at the time of the standup. The only preparation necessary is for each team member to think about how to present the work being done at the moment in such a way that it’ll be clear and understandable to everybody. if a team member is having blockers that relate to people outside the team, it’s reasonable to let those people know to be prepared to discuss the issue immediately after the standup.

There’s no special preparation needed by the scrum master before the standup. A good scrum master may check the status of the stories being worked on before the standup, to see if any changes are pending, or may arrange to round up any guests the scrum master thinks should be there who don’t normally attend.

Three Questions

The core of the daily standup consists of the scrum master going around the team and asking every person three questions:

• What have you done since the last stand up?

• What do you plan to do until the next standup?

• Is there anything blocking your progress?

It should be as simple as that. Every member of the team answers each one of these questions, and once the last person has finished reporting, the standup is over. Unless the scrum master has urgent announcements that need to be made for the entire team, everyone who doesn’t have specific business with another person attending the standup should be free to get back to work.

Warning: Beware Guests at Standups

There’s a strong tendency for people attending standups as guests to ask questions, introduce new information, or start discussions that don’t relate to the entire team. Anyone who isn’t a member of the development team shouldn’t be speaking during standup. The scrum master needs to be strong about suppressing this kind of behavior. People of high rank in the organizational hierarchy don’t get special treatment in this regard. Everyone needs to respect the time and attention of the engineers, and allow them to get back to work as quickly as possible.

In answering the questions of the standup, each engineer needs to be prepared with a succinct description of what they’ve worked on, what they plan to work on next, and whether they have any blockers. This is a skill that takes practice, and the scrum master should be prepared to coach every team member on how to answer these questions in a way that makes the best use of the time available.

If one person’s report invites a little bit of back-and-forth discussion, and the conversation has relevance for the entire team, the scrum master may permit it. But this type of interaction must be limited to respect the time box of the standup. If the conversation gets beyond a few sentences, the scrum master should step in and suggest that the conversation be taken off-line. A good scrum master will keep track of what conversations need to happen at the end of the standup, and follow up on their status afterward.

Other Status Updates

Some teams choose to update the status of their stories on the team’s shared scrum board during the daily standup, while others prefer to do it individually as the stories get completed. In either case, the standup should be an opportunity to make sure everybody has updated the status of everything they’re working on, and that everybody on the team is aware of what everybody else is working on.

For teams that are doing pair programming, the standup can be an opportunity to switch pairs, or switch stories. Some teams that do pairing prefer that every story have one engineer seeing it through from beginning to end. It can be beneficial for the flexibility of the team to allow multiple people to pair on the same story, particularly if it relates to some core functionality that’s worth sharing information about. Different teams will come up with different approaches, but the standup is a good place to make changes on a daily basis.

Standups are also a good opportunity for team members to let each other know if they expect to complete a story before the next standup, and if they have vacation time coming up. Knowing the availability of other people on the team can inspire teammates to plan their work around upcoming stories, and arrange to switch pairs or allocate resources appropriately.

Note: What to work on next?

If an engineer is unclear about what should be worked on next, the priority of the sprint backlog should guide these decisions. The product owner is responsible for grooming the sprint backlog throughout the sprint, and making sure that it always represents the priority in which the stories should be addressed.

Unless there’s a compelling technical reason, any engineer without a current story should start working on the story at the top of the backlog with the next highest priority, regardless of specialization. Following this pattern can provide an opportunity for engineers to pair with somebody in an area where they have less experience, and help spread knowledge about the entire code base throughout the team.

Finally, the scrum master may make announcements that have relevance to the entire team at the end of the standup—once everybody has had a chance to report, and only if there’s time left. This shouldn’t become a replacement for any organizational team building that may come from company meetings, team lunches, and other gatherings.