How to Use the Daily Stand-up Meeting Effectively

26 June 2012

Daily stand-up meetings play an important role in the success of Scrum process-based projects. Most of us know this, and we know how they "should" be conducted. Yet, time and again, I see these meetings go astray. Here I hope to review the problems I commonly see, plus some solutions. I also hope to hear back from others about how they maintain the effectiveness of daily stand-ups.

It's often more important than we realize to guide and coach our teams about the usefulness of daily stand-ups. And it's worth it: Successful stand-ups can guide sprints throughout a Scrum-based project. Here are some useful tips:

 

Process discipline

Teach your team the basic ways of using time during the daily stand-up. Then be sure to follow them:

  • The daily stand-up should be time-boxed.
  • The ScrumMaster should facilitate regular daily meeting times. Don't change the time of this meeting if you can avoid it; Scrum requires discipline.
  • Each member of the team should participate in this meeting. In some organizations, senior expert members sometimes hesitate to join. The ScrumMaster should coach them about the importance of their participation and the help they can provide to the team.
  • Don't update the sprint backlog during this meeting.
  • Team members should be active listeners so they know how the team as a whole is doing, and so they can help one another resolve impediments.
  • Ensure that each team member remains present till the end of the meeting. Sometimes members want to leave after updating their own work plan, but the purpose of the stand-up is to understand how well we're doing to achieve sprint goals as a team.

 

Sprint status disclosure

 

In addition to respecting the basic processes outlined above, there are more subtle habits to maintain during daily stand-up meetings. One is the discussion of any impediments. It's easy for some members not to mention impediments — or to get bogged down in a long, large-group discussion of impediments that are relevant to just a few team members. Here are some ideas for avoiding these problems:

 

  • Remember that the daily stand-up call is not a status meeting. The ScrumMaster needs to pay attention to make sure stand-ups don't tend in that direction. Guide team members to be open about their work progress and any hurdles, be they individual or team-wide.
  • Use the stand-up to get any needed clarifications from the product owner (PO) regarding requirements (user stories) and sprint release issues.
  • The ScrumMaster should list all the impediments faced by the team and help resolve them on a timely basis.
  • Any technical discussion should be conducted after this meeting; only relevant members need to attend the technical discussions.
  • The ScrumMaster will need to pay special attention to new Scrum teams, to help them follow the most effective stand-up processes.

 

Working with the product owner

Some specific tips make for best communication with the product owner during daily stand-up meetings. These are my suggestions:

  • The team should think of daily stand-ups as a way to communicate effectively to the product owner, in addition to each other, about progress. No one wants any sudden surprises at the end of the sprint; these can be avoided if team members give regular and accurate updates during each daily stand-up.
  • By the same token, the product owner should commit to attending this meeting daily so that he or she gets a better picture about team's commitment for the current sprint.
  • The stand-up should go forward even if the product owner or the ScrumMaster can't join on a given day, whatever the reason.

 

Hurdles faced by new teams

Scrum isn't easy, as we all know if we've been able to dive deeply into it. It demands commitment from each team member, and new members aren't always used to this work culture. Below are some hurdles commonly faced by new Scrum teams:

  • Lack of process knowledge: New Scrum teams need coaching and training about the Scrum process so they can effectively use the daily stand-up for its intended purpose. However obvious the process seems by now to the ScrumMaster, he or she needs to provide this coaching and process knowledge to new teams. In the same way, each team member must actively participate, to communicate how the team is doing and to fully learn the daily stand-up process.
  • Hiding work details: It's important that every team member is transparent in his or her work and gives accurate updates. Members need to disclose any issues so they can be resolved on time, without impacting the entire team's commitment for the sprint. The ScrumMaster can help here, particularly in the realm of being transparent to the customer and encouraging the kind of customer involvement that can lead to a successful sprint. The daily stand-up isn't just about answering the same three questions every day; it's a perfect forum for discussing any gaps in the team's commitment and understanding of requirements.

 

Comparisons with the Waterfall process

New teams will almost invariably try to relate the Scrum-based process to Waterfall. This, however, is something to avoid. It's important to follow Scrum fully and correctly, and it's the ScrumMaster's job to make sure his or her team knows how to do this.

Not only is the team culture different in Scrum but the way the team works with the customer is usually different as well. This is another area for the ScrumMaster to focus on, since working with the customer is key in Scrum.

My hope is that the suggestions above can help guide new teams — as well as experienced ones — through the daily stand-up. Using this meeting as effectively as possible can set the tone for the entire sprint, helping a team understand its own progress and reach success.

Article Rating

Current rating: 0 (0 ratings)

Comments

Greg Manto, CSP,CSM,CSPO, 6/28/2012 5:57:52 AM
Very good article for prompting a review of ones own basic stand-up practices. My one recommendation is to consider how to balance fast/value-adding team interaction with the operational management of a project when time (personal and work time) is limited. With that as a backdrop, I typically challenge the notion of "don't update the Sprint Backlog during Stand-Up". In theory, I agree that the meeting should be primary about the team interacting, bubbling up dependencies/impediments and setting the stage for deeper discussions afterwards but there is also an integral administrative foundation task which also needs to be served. Specifically, at some point the backlog/tasks/defects need be made "current" at a high level and with all eyes on the ball. One might say "after the meeting, the SM or PM or lead or individuals can easily update the backlog/tasks/defects" and that should absolutely happen, but there are aspects which, if updated during the stand-up's, keeps the teams "launching pad" at a higher level from which to work from each day. For instance (with the help of some of the great tools out there these days), we have our backlog up on a large screen (and shared, with audio, with our remote team members) and each person answers their questions with the backlog as an immediate reference tool (e.g. "the impediment I am facing with User Story zzz is that the task aaa requires myself and..."). By continually encouraging inclusion of these explicit backlog references as integral to the dialog, it becomes a very simple process of (whomever is hosting the meeting) to quickly add comments to the item on the backlog as the dialog is occurring and thus partially dynamically create the action plan for the day in a way which is easily referenced as part of everyone's daily process. This approach also creates value in how the team names their emails (e.g. Subject: UStory 345 - who knows browser config for...) for those emails which may go out outside of what your scrum tool sends.

Granted, like all aspects of communication, each team will need to determine their balance. Something to consider.
Douglas Ross, CSM, 7/6/2012 5:52:19 PM
To add to Greg's comment, if you are working in a distributed team having a "shared space" is very important. I put the task board in front of the team. If updating it is slowing the meeting down, then a compromise can be made but more often than not doing the work in the moment makes the meeting tighter because by the end there is a feeling of closure - not "oh, wait for me to update this before..." the team can get to work.

There is another common phrase I take issue with, "The daily scrum is not a status!" If the three questions are not status then I don't know what is. The reason this refrain became popular is because we wanted to discourage managers from participating in the daily scrum. Managers were skewing the discussions and inhibiting collaboration. And if the product owner is in the meeting (I'm torn on this practice) then this is very much a status for them.

The real value from the daily scrum is for the team to discover how they can best help each other to meet its sprint commitment. To this end it needs to feel free to discuss work, openly and without regard for external observers. I like to say the team can air it's dirty laundry in the daily scrum, like the family meeting - outsiders are not really welcomed. The team needs a place where they can talk without fear of being evaluated or scrutinized by outsiders, especially by managers who might impose consequences. A team member might be less likely to admit a mistake or lack of knowledge if the person who writes her annual review is listening in. But this member's issue could be critical information for the team to ensure sprint success. And so I would qualify the "not a status" suggestion with the point that the daily scrum needs to be a safe place for the team to discuss its work: the good, the bad and the ugly.
Greg Manto, CSP,CSM,CSPO, 7/8/2012 11:26:13 AM
I agree with Douglas.
Ken Fisher, CSM, 10/28/2012 11:22:37 AM
Great post: Regarding "Use the stand-up to get any needed clarifications from the product owner (PO) regarding requirements (user stories) and sprint release issues." I love the practice of having the PO in the stand-up, but have learned the importance of the PO fully understanding the intent behind the stand-up. I've found that the PO can most effectively assist the team by being led to speak in terms such as "As a User, I want to be able to... so I can..." Without that modeled behavior, the discussion can go way off course and confuse the team. If the discussion does need to go much further than that, we generally set up another meeting so the other team members can get to work.

You must Login or Signup to comment.