What is the best part of the day to have the Daily Scrum meetings, in the morning or afternoon?
There cannot be a single, canonical answer to this question that will be true for all teams and all projects. However, there are certainly some common practices—but keep in mind that "common" doesn't necessarily mean "best."
To clarify the trade-offs involved in selecting an optimal time for your daily stand-up, I will provide some concrete examples of how the Daily Scrum meeting should be used. Once your entire team shares a foundational understanding of what the scrum is for and how to leverage its format to best advantage, it is much easier to make the necessary fine-tuning adjustments to find out what works best for your team.
Naturally, I have some pragmatic advice about that, too. In the general case, starting your daily stand-up 30 minutes after the start of your team's "core hours" will serve many teams well. While not universally true, it is a reasonable proxy principle to use as a starting point until you can empirically define the optimal meeting time for your team, in your organization, and in your field of endeavor.
Understanding the Purpose of the Daily Stand-Up
Each of the three questions asked during the Daily Scrum is is equally important for the intra-team coordination required of a successful Scrum Team. It is a mistake to make any one of the questions as more important than the others. As @jessehouwing correctly points out:
The most important goal of the daily scrum is not to identify problems, but to create a plan for the next 24 hours (until the next daily scrum).
To put it another way, the goal of the daily stand-up is to allow the team to coordinate its activities. The "three questions" provide a framework for team members to do the following:
Identify completed work that ready to be pulled into the next column of the team's pull-based work-flow.
What did you do yesterday? should elicit a work item from the person currently handling the widget-embiggening story. This person is communicating what parts of the work are done, and ready to be pulled into the QA column by the person on the team who is best able to handle the Selenium or Capybara testing that is part of the story's Definition of Done.
Identify queue capacity, and coordinate the hand-off.
What are you doing today? should elicit a team member's expectation of what work he is ready to pull so that two people don't try to grab the same story. This question should also elicit task or story dependencies, and can make implicit expectations explicit. For example, when Team Member Bravo says "Today I plan to embiggen the Foo Cascade," that person is communicating that:
- What was on Bravo's plate yesterday is done, and has available capacity.
- Bravo is committing to work on embiggening the cascade today unless the self-organizing team identifies something else that takes priority.
- The work that Team Member Alpha said was on Alpha's plate yesterday is now needed by Team Member Bravo, and Alpha should speak up if the Foo Cascade isn't ready for Bravo to embiggen it yet.
- If Alpha and Bravo need to coordinate the hand-off in more detail, they identify the need and plan to take the additional coordination off-line. For example, Alpha might say: "The cascade is ready for you, Bravo, but let's get together after the scrum so that I can explain how to insert Tab A into Slot B before the embiggening can begin."
- Bravo is letting the team know that, if all goes well today, the person who will pick up the Foo Cascade tomorrow for testing (we'll assume this is Team Member Charlie) can plan his work accordingly, since there is now an explicit expectation of when the user story will be ready for the next step in its journey.
Identify any new tasks or stories that may require changes in the team's Sprint Backlog or require additional coordination or support from other team members.
Do you have any roadblocks? should elicit a brief list of things that are standing in the way of a clean hand-off between team members. For example, Team Member Charlie might be unable to test the Foo Cascade because the Quux Capacitor is leaking. Charlie brings this up as a roadblock so that the team can discuss it briefly to determine what resources they have to address the problem (if any), who will write the task down in the Sprint Backlog if that hasn't already been done, and who should take interim ownership of the unblocking task.
Continuing this example, we just learned that Team Member Bravo has cleared his plate, and there's no point in Bravo working on embiggening the Foo Cascade until the Quux Capacitor leak has been fixed since Charlie can't pull the completed work while this roadblock is in place.
This sort of cooperative problem-solving is sometimes called swarming or stopping the line, and is the Scrum way to allow the team to maintain flow and cadence throughout the Sprint. It also leverages process slack and collective ownership to dynamically allocate resources to user stories in a way that command-and-control management generally cannot reproduce or coordinate as efficiently.
Some Practical Advice
While there can't be a canonical answer to the question of when meetings should be held, there are certainly some pragmatic considerations.
In a self-organizing team, a common practice is to have "core hours" when all team members are available to each other. For example, a team may have core hours between 10:00am and 2:00pm, but people may come in earlier, work later, or have an entirely performance-based schedule outside of those core hours. Scheduling the daily stand-up near the start of core hours is often the best way to ensure that there's plenty of time for intra-team coordination following the stand-up.
Holding the scrum too early may result is lower productivity from those who aren't morning people, and doesn't give folks enough time to review the day's work or prepare coherent data for the scrum. Make sure people have at least enough time for a cup of coffee and a chance to check their email, CI build status, or other metrics before expecting a scrum to yield meaningful results.
Holding the scrum too late in the day doesn't leave enough slack in the process to handle unforeseen events, and doesn't provide the team the ad hoc post-scrum meetings they may need to coordinate between themselves.
In my own experience as a Scrum Master, holding the 15-minute daily stand-up 30 minutes after the start of core hours (e.g. holding the scrum from 10:30am-10:45am when core hours are 10:00am-2:00pm) is empirically the best strategy that I have found. However, other strategies are also valid, so your mileage may certainly vary.