Over fifteen years of experience leads me to believe that most Developers dislike — and frequently despise — the Daily Scrum. Many view the event as a waste of precious time. Others perceive the meeting as a form of micromanagement. Some would rather replace in-person interaction with Slack. How did people practicing Scrum devolve to this dismal state?

In this essay I’ll explore techniques ScrumMasters can use to help restore the Daily Scrum to a productive opportunity that Developers actually look forward to . . . 

Facts and Fiction

One reason the concept of the Daily Scrum fails in practice is that it is misunderstood. Three typical misunderstandings are clarified below.

  1. The Daily Scrum is not a status report to some manager. It is a daily planning session for the Developers. Many Scrum Teams begin practicing Scrum lacking this basic knowledge. In fact, in the most recent version of the Scrum Guide, the co-creators of Scrum say that the Daily Scrum “produces an actionable plan for the next day of work.” The Daily Scrum is a key inspect-and-adapt meeting for the Developers.
  2. The Daily Scrum does not need to follow a “three question” format. In fact, the Developers can choose whatever approach, or format, that most effectively allows them to focus on progress toward the Sprint Goal. Again, from the Scrum Guide, “The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal.”
  3. The ScrumMaster is not required to “run the meeting.” This is a very important distinction because the ScrumMaster only has a few responsibilities related to the Daily Scrum. One, the ScrumMaster is responsible to coach the Development Team to keep the discussion within the fifteen minute timebox. Two, the ScrumMaster ensures that others do not disrupt the meeting. Three, the ScrumMaster ensures that the Developers have a daily meeting to discuss progress towards the Sprint Goal. As you can see, none of the ScrumMaster responsibilities includes “running the meeting.” The Scrum Guide is clear that the Developers are responsible for conducting the Daily Scrum. 

Techniques to Fix the Daily Scrum

  1. Schedule a team conversation about the Daily Scrum.
    Copy the Daily Scrum content from the Scrum Guide and paste it into a document. At the meeting, ask the Developers how they want to conduct
    their Daily Scrum. During your discussion, ensure awareness of the following clear constraints offered by the Scrum Guide:

    • Focus on progress toward the Sprint Goal
    • No more than 15 minutes
    • Held every day of the Sprint to inspect work and forecast work
    • Results in a clear plan through team collaboration
    • Same time and place each day
    • Detailed discussions to occur immediately after or throughout the day                
  2. Eliminate the Three Questions.
    The Three Questions usually degrade to rote statements of little value, “Yesterday, I worked on ticket 12218. Today, I’ll keep working on 12218. No impediments.” No wonder Developers do not see value in this meeting. More significantly, the result of answering the three questions does
    not result in a plan for the day, failing to achieve the purpose of meeting! If the Developers need an alternative idea, I suggest proposing an item-by-item review of the Sprint Backlog.

    • First, one of the Developers leads the Daily Scrum (the role can rotate). The meeting begins by reviewing any Sprint Backlog items that have been completed in the past twenty-four hours. Celebrate the win! Clap, woot, make goalposts with your arms, whatever.
    • Next, the Daily Scrum leader reviews any items in progress. For example, they could point at an item in progress in the Sprint Backlog and say, “What progress did we make on this item yesterday?” Then, whoever is working on that item, and it is likely more than one person, shares the progress they made since the last meeting.
    • After that, the leader asks this vital question, “What’s our plan to make more progress on this item today?” Whoever is needed to work on that item discusses the plan. At this point, the discussion will progress naturally and need little intervention from the leader.
    • At an appropriate point in the conversation, the leader asks, “What are any impediments to progress for this item?” Be prepared for potential impediments like a dependency to someone outside the Scrum Team or lack of access to a key physical resource. The ScrumMaster must listen for and track this discussion for action following the Daily Scrum.
    • Next, the leader moves on to any other items in progress following the same pattern. Finally, the leader can ask, “What will we do next when we finish any items?” The discussion then usually focuses on what Sprint Backlog item might be started next.
  3. Save the DayDon’t Be a Scrum Superhero
    Allow me to save you many years of failure I experienced when coaching teams at Daily Scrums — resist the urge to be a
    Scrum Superhero. I vividly recall jumping into poorly executed Daily Scrums to save the Developers from themselves. I pictured myself jumping in with a cape and hands on hips saying, “Here I am to save the meeting!”

    • If the meeting is a train wreck, restrain from intervening. Seriously . . . just let it go. Allow the dysfunction to go on until the Daily Scrum is over. Then, choose your interventions to assist the Developers very carefully. When a bad meeting finally ends, ask a simple question, “Would you like some help?”
    • If the Developers say, “No,” and sometimes they do, allow them to move on with their day. Sometimes a poor Daily Scrum, one that lasts thirty to forty-five minutes (or longer!), generates such anxiety that not intervening is the best option. However, be sure to make a note in your ScrumMaster journal and move on with your day.
    • If the Developers accept your offer to help, begin by asking questions to help the team clearly identify what happened to cause the poor outcome. Ask questions until the Developers name the issue. If they cannot name the issue, they cannot decide whether to resolve the issue. Next, ask them what they will do when that same issue arises in the future. The key to this intervention is not to solve the Developers’ problem. Instead, use questions to guide the Developers to self-improvement.
  4. Give the Daily Scrum Back to the Developers
    Try these final, straightforward ideas to clearly signal ownership of the Daily Scrum by the Developers.

    • If you set up the Daily Scrum on everyone’s calendar, cancel the invitation. Anyone of the Developers is perfectly capable of sending out a new invitation, if needed.
    • If the Developers are distributed in different locations, do not control the virtual meeting. Do not start it. Do not run it. If necessary, acquire a videoconference or teleconference account for the Developers and give it to a volunteer to manage. Or give them your account to use. Either way, the Developers are perfectly capable of running their own collaboration tools.
    • Absolutely do not move Sprint Backlog items on physical, or virtual, boards. The Sprint Backlog belongs to the Developers, not the ScrumMaster. Therefore, a ScrumMaster has no business moving things around the Sprint Backlog or reporting progress. Leave that to the Developers. (The ScrumMaster does have a responsibility to remove impediments to progress as fast as possible, but that is a different topic unrelated to the Daily Scrum.)
    • The Developers may review a tool for visual reference, e.g., JIRA, CollabNet, Azure DevOps, etc., during the Daily Scrum instead of physical cards. Whether the team meets in-person or online, encourage the team to display a view of the Sprint Backlog on one screen without any scrolling. I find this technique helps maintain a higher level focus on progress toward the Sprint Goal without veering into excessive detail.
  5. Inspect the Daily Scrum periodically during Sprint Retrospective.
    Here are some questions/topics to ask the Developers to further spark reflection and improvement in the Daily Scrum.

    • Rate the quality of your communications.
    • Evaluate whether the Daily Scrum has eliminated other meetings. (It should. If not, find out why.)
    • Measure speed of decision-making as a result of daily synchronization.
    • Assess improvement of their level of knowledge from the meeting.
    • Ask how valuable the Daily Scrum has become for them, then inspect-and-adapt.

For more on tools and tips, see this article with more ideas on how you can further fix your Daily Scrum.