I was used to morning Daily scrum meetings (after 30/60 mins of work), but currently we are conducting meetings after 6 hours of work. I think this approach has the advantage of focusing on the problems the team members have encountered when they answer the "Are there any impediments in your way?" question. I believe that this is the most important of the three questions that the team members answer.
What is the best part of the day to have the Daily Scrum meetings, in the morning or afternoon?
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.
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:
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.
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.
In general, all interruptions to the mental "flow" of highly concentrated knowledge workers are counter productive and so the timing, duration and structure of the daily need careful consideration.
Having tried a few variants I prefer to hold the daily 30 mins after everyone is in the office. The reasons are:
There's enough time for the majority of the team to "warm up" with a coffee, some small admin tasks like emails, and to get their heads back into yesterday's work. However it's before they've gotten themselves into the mental zones necessary for quality work to be achieved.
It allows people to form a plan for the day and to articulate this in front of the rest of the team. Verbalizing builds belief and as with any team sport a "huddle" timed at the start of play builds motivation and momentum.
It allows sufficient time before the close of business for the scrum master to plan and execute any impediment-blitzing activities which might be necessary and it also allows the team enough time to schedule pair programming sessions and other coordination / knowledge sharing meetings.
Without wanting to get too deep about this, in general I think human beings are innately programmed to follow daily rhythms of behavior, starting afresh in the morning and closing down in the evening. They also operate better if they feel like they have a direction or a plan from the get-go and so an early daily would be my recommendation.
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).
It doesn't matter when exactly you do the daily scrum though. I prefer it in the early morning if all team members tend to arrive around the same time. If team members come in at different times I generally suggest teams to pick their favorite slot. Many teams do a daily just before or just after lunch. Which is a natural break in your 'vibe' anyway.
When a team member encounters a problem during the day, it's best if they work together to solve it.
The daily scrum may identify possible issues in the further future, that may impact your teams ability to complete the sprint goal, those are the ones the 3 questions focus on.
Generally speaking, a morning meeting is better, because
Of course, if the team members are not in the office in the morning or you have more than one sites with time difference, you have no other choice than keep the meeting at a time that is suitable for everybody.
The convention is in the morning, but the answer is it depends on the needs of your team.
In choosing a time for the daily scrum, consider the following:
What time zones are team members in? If your team is geographically distributed, then choose a time that respects the working hours of as many team members as possible. If someone has to attend scrum at 3am, then consider alternating every few sprints to share the inconvenience.
What fits team member lifestyles? Some people like to start their day later than others. I often like to work through midnight, so can't stand a 7am daily scrum because then I'm getting to work untested and unproductive. Similarly, some people have kids and need to leave the office to pick them up after school. So your team's needs will vary.
Where is the team's customer and what are that customer's communication needs? This question applies more to the scheduling of product demonstrations, but if the team's customer or manager will attend a scrum then it is important to consider what times of day will work for that stakeholder. This is more important if the customer is using feedback from daily scrum to understand and communicate how a vendor is performing.
What pace is the team working at? If the team rarely completes a task between scrums or is a part time effort for most team members, then it can be frustrating for team members to meet every day. Consider adjusting the frequency of scrums to fit the realities of the team. Augment in person meetings with other forms of communication.
In the Morning. First thing.
The most important thing to do in the daily scrum, is to say what task you are working on that day.
This gives immediacy and allows no equivocation, ie. "I know I said yesterday that today I would do X. But I forgot/slept on it/changed my mind"
It also deals with the problem of people not turning up. ie.
Our team usually do daily meeting at 13.00. This is the time that team agree and every team member can attend the meeting with no problem. In meeting, we plan for next 24 hours what we are going to finish.
Choosing daily meeting in morning or afternoon, I think it depends on your team agreement and availability. Some teams prefers in morning, others in afternoon.
