The Modern Guide to the Daily Scrum Meeting

“I worked on JIRA Ticket …, I’m still working on…, No Blockers”. Meanwhile everyone else is staring at their phones or is distracted by email. Does this sound like your Daily Scrum? The problem isn’t the event, Daily Scrum done well is helpful. The problem is what it has turned into: the dreaded status update.

Daily Scrum isn’t a status update. Nor is it about answering three awful questions.

What is the main purpose of a daily scrum meeting?

I don’t run around quoting the Scrum Guide as if it is the final word on anything, however it does provide a good starting point:

“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

In my workshops, I tell people the daily scrum purpose is to:

• Improve communication
• Prepare the team for the day’s collaboration
• Help the team sense whether they will meet the Sprint Goal
• Find anything that is slowing the team down towards meeting the goal

If your team is struggling with Daily Scrum, always come back to the purpose to see if you’re achieving it or not. Daily Scrum isn’t the only time adjustments can be made to the Sprint plan, but it’s certainly a great opportunity.

At the end of a Daily Scrum:

• The Sprint Backlog should be updated
• The whole team should understand their current state of progress towards the Sprint Goal
• The whole team should understand what impediments (or slowdowns) exist

Is Daily Scrum the same as Daily Standup or Daily Huddle?

Yes. Daily Standup is the common name for Daily Scrum and, frankly, if it gets the team standing then it’s a better name. Daily Huddle is the term commonly used by the Lean Community.

Who attends Daily Scrum? Does the Product Owner attend? What about Managers?

According to the Scrum Guide, “the Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.”

But I differ with the Scrum Guide on this. I think a good ScrumMaster makes an excellent facilitator and, in that capacity, might help the team. Whether they attend Daily Scrum or not, I would expect the ScrumMaster to work with team members to start removing the impediments, escalating to management if the problem can’t be solved within the team. We say this time and time again in workshops, the ScrumMaster is responsible for removing impediments, but often the best way to do this is to get the rest of the team to help.

And many Product Owners whom I’ve coached attend the Daily Scrum event so they can hear about misunderstandings about their work, and impediments towards achieving the Sprint Goal. In the best cases, I’ve seen Product Owners resolve impediments right after the Daily Scrum event finishes, because they were present to hear more about the obstacle.

Managers don’t attend Daily Scrum unless they’re acting as a Developer/Doer of work for that Sprint. Even in that case, the power imbalance means that the Daily Scrum might turn into a reporting event, instead of a collaborative event.

Where, When and Timebox of Daily Scrum

Where should teams hold their Daily Scrum meeting?

Pre-pandemic, I recommended that teams meet for Daily Scrum in their team room and ensure that everyone can see the Sprint Backlog. Now our teams are often either hybrid or fully remote, and I don’t see many team rooms. However, it’s still important that everyone on the team can see the Sprint Backlog during Daily Scrum. This is their way of visualizing the current state of the work. In addition, seeing the Sprint Backlog makes it easier to determine as a team whether they still believe they can meet the Sprint Goal.

When should Daily Scrum happen?

The earliest in the day that it is practical for the team to meet. If your teammates have younger kids, that might not be until after the school bus leaves. Since the event is truly self-organizing, it has to be up to the team members. The Daily Scrum is timeboxed at 15 minutes long. That keeps the event focused and high level, minimizes the risk of long side discussions.

How to Handle Time Zones in Daily Scrum

When your team is spread across time zones, scheduling gets harder.

If the team is spread from St John’s, NL to Vancouver, BC (a 4.5-hour difference) the obvious choice is to select the earliest time that is practical for the BC team members. Teams with this time difference usually benefit from setting core hours and creating other working agreements.

At some point, the team has no overlap in the day. (Vancouver and New Delhi) What do you do in that case? Others will suggest the use of asynchronous tools. I think we need to ask a more fundamental question. Can a group of people with no overlap become an effective team? Unlikely.

The only band-aid strategy that I have seen work? Have sub-teams in each timezone and then someone attends the other team’s events. In one week, someone from Vancouver is inconvenienced and attends the New Delhi team’s events. In the next week, the circumstances are reversed. This is far from optimal.

In almost all cases, we’re better off not pretending that groups of people who don’t have overlapping time are a team. Instead create two (or more) teams. Each team works from the Product Backlog independently from the others.

Does Daily Scrum Have to Be Daily?

Meeting daily feels like a hassle, does it really have to be daily? Let’s check back on the purpose of the event: update our Sprint Backlog (aka the plan), check progress towards our Sprint Goal and identify impediments.

It’s held daily because of the benefit. If your team isn’t seeing the benefits, instead of changing the frequency take the time to understand why.

Why is the Daily Scrum the same time, same place every day?

It reduces complexity and makes this Scrum event a habit.

The Three Daily Scrum Questions

One thing that people seem to believe about Daily Scrum is that there are three famous questions:

• What did you do yesterday?
• What will you do today?
• What are your blockers?

Back in the mists of time, questions like this did appear in the Scrum Guide. The challenge is that they’re reductive. They get people to focus on task work, but not the Sprint Goal, and not even the current feature or User Story they’re working on. The narrow focus of those three specific questions also misses the collaborative nature of work.

Often the answers reveal no useful information. Common examples:

• Yesterday, I spent my fifth day working on …
• Today, I will spend another day working on…
• I have no blockers.

With answers this repetitive and simplistic, the team has missed an opportunity to more effectively plan the day.

There have been many changes to this section of the Scrum Guide over time. We will just focus on the most recent (2020) version:

“The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.”

So your team might consider getting rid of the list of questions altogether. There is no magic to three questions. Some ideas to spark your thinking:

• Which story or feature on the team needs the most help?
• Which story or feature is closest to being done? This is asked with the Kanban mindset to focus on finishing work before starting new work.
• Where would you like help?
• Where is your biggest challenge?
• Where is the team’s biggest challenge?

A recent CSP-SM attendee said: “I became a scrum master in 2022, and some of the folks that I work with on scrum teams still default to this format/language. Tactically – it’s easy to understand why as it seems to streamline the standup and quickly ascertain if things are on/off track, that people understand what they’re working on and are making progress, and surface whether there are any issues. The difficulty with this format is that the closed-ended nature of the questions does not foster a collaborative approach. I coach the scrum masters that I work with to facilitate a discussion with the scrum team that is focused on the sprint goal, rather than checking off the box on the three questions. It has helped to shift the focus from viewing their work as tasks that each individual is responsible for to thinking about their work fits into the big picture of what the team is trying to accomplish together and has helped us discover dependencies that might have otherwise been missed until something was broken.”

I believe the above comments perfectly encapsulate the benefit of abandoning the formulaic questions and changing the focus of Daily Scrum.

Story by Story and/or Walk the Board

Some teams change from a person-by-person focus to a story focus. In this case they walk through the Stories that are “In Progress”. If anyone is working on things that are not on the Sprint Backlog, they’re encouraged to add it to the board. (Or drop it if it is not relevant to the Sprint.)

We go further and take a leaf from the Kanban world. Since we’re trying to get items to done, try:

• Start with the items closest to done (i.e. rightmost) and work back
• Items get discussed by the people working on them
• Items that are stalled or waiting for a dependency get additional attention

Why right-to-left: reinforces the Kanban mindset of finishing work before starting new work.

The whole point is to experiment and find a structure that works best for your own team to increase communication and engagement.

Characteristics of a Good Daily Scrum

• Replaces all other meetings in the day. This almost needs to be in big, gold lettering. Having planned for the day, team members shouldn’t need to attend any other meetings, other than the obvious Backlog Refinement.
• Short. No one feels engaged when a meeting runs on for a long time, so Daily Scrum is timeboxed to 15 minutes. Even with remote Daily Scrums on Zoom, I recommend that people stand. Sit-down meetings often drag on. Standing helps people focus.
• Everyone participates. Participation means not just sharing your update, but actively listening to what other people are planning to do. Collaboration happens when you hear someone else planning to work in an area where you have recent experience. You might set aside some of your own plan to help them get through a difficult problem.
• Honesty. Team members need to be open and honest about the challenges they face and, if they need help, even a little bit, they should ask. This, of course, requires the team have established Psychological Safety.
• Focused on Sprint Goal. Some teams reread the Sprint Goal to start their Daily Scrum. Whether or not they do, their thinking about what they plan to do that day and what impediments exist, should be centered around the Sprint Goal.
• Sprint Goal Confidence Check. Some teams ask “On a scale of 1-5, how confident are we that we’ll meet the Sprint Goal?” This makes the Sprint Goal focus concrete and actionable. It surfaces concerns early (someone holding up a 2 forces a conversation).
• Solve impediments after the Daily Scrum. Most impediments are only germane for a few people. Rather than try to resolve them in Daily Scrum where it occupies the time of all team members, consider discussing them in more detail after the meeting with only those who are affected.
• Parking Lot. If anything in the Daily Scrum turns into a long back-and-forth discussion, use a Parking Lot.
• Process Improvement. Along with the Sprint Goal, the Daily Scrum helps track progress on the improvement(s) agreed to in the last Sprint Retrospective.

What Happens After Daily Scrum?

This is where the real problem-solving happens.

Remind the team of the issues/impediments that were discovered. Invite the people who have the impediments and the people who can help to stay back. If the impediment is a bigger issue, the ScrumMaster may need to reach outside of the team to get more help.

If there was anything in the Parking Lot, either resolve right away or get the people who care to set up a time to solve it.

One pattern that works well: at the end of Daily Scrum, anyone can say “I need 5 minutes with [names] to discuss [topic].”

In a world with widely distributed teams, we often lose the social connection. Some teams I’ve worked with keep their Zoom connection open for a while after to socialize. In other cases, team members post office hours and hang out in Zoom happy to chat with whoever swings by.

Sitting or Standing? How should the Daily Scrum go?

A good practice is for Scrum team members to stand during the Daily Scrum event, if physically able. The thinking:

• Nobody wants to stand for very long, so it helps keep the meeting short and focused.
• We’re away from our computers so there are fewer distractions.
• We stand in a semi-circle and face the Sprint Backlog / task board, so we all share a common reminder of the purpose.
• Standing keeps the conversation focused on the tasks and helps us to keep from drifting off track.
• Daily standup helps us avoid reporting to a leader, and instead we’re reporting to the rest of the team.
• Standing can be done in the team area and doesn’t require a meeting room, which helps us stay in the context of our work.
• Standing keeps the energy level up.

Remote Scrum team members are also encouraged to physically stand in front of their camera during Daily Scrum. Sitting in front of their computer creates multiple distractions, but standing away from the keyboard reduces that temptation.

Pitfalls of Bad Daily Scrum

As I wrote in this Scrum by Example post with our fictional ScrumMaster, some teams feel pain in their Daily Scrum. If you know someone who hates Daily Scrum (maybe yourself?), it likely stems from one of more of these common poor practices:

• Scrum Master telling people whose turn it is to speak
• Too much personal socializing, wandering off topic (Hint: one group I worked with leaves the zoom session open after Daily Scrum so team members can catch up outside of the meeting timebox)
• Team members consistently late or not showing up
• Directed rather than self-organizing. Example: one person taking over and telling team members what to do
• Devolves into a status meeting, where it’s more reporting directly to a manager than it is sharing with the team
• Trivial and tedious, reporting in so much detail that no one understands or cares
• Repetitive. Example: someone saying that they worked on the same user story several days running
• Not raising impediments
• Not prepared. It only takes a few minutes of reflection to consider the Sprint Goal and plan what the next most important thing you could do.
• Problem solving. The team gets lost in the weeds of a good problem-solving discussion. My suggestion to teams? Consider capping the discussion at 1 min and resolving after Daily Scrum.
• Too many people in attendance. If your Daily Scrum is larger than a normal sized Scrum Team, it will take far too long. When this comes up in workshops, the leading cause is that the Scrum Team itself is too large.
• Notetaking and meeting summaries. The event is intended to help plan the day, so meeting notes are pointless as they would only be meaningful for a few hours. Further, aside from impediments, there is nothing we would expect to be shared since sharing information from Daily Scrum outside the team will reduce honesty and transparency, and people will protect themselves from the perceived risk.
• Some team members attending multiple Daily Scrum. Let’s talk about this one in more detail …

Attending Multiple Daily Scrums

Most of the time when I hear the complaint, “I’m attending three Daily Scrums. When do I have time to work?” the person is assigned to multiple teams. This isn’t what Scrum intends. You can’t effectively be a part-time team member on three teams. This is the classic multi-tasking problem/misconception.

So you shouldn’t be attending multiple Daily Scrums because you’re on multiple teams, but if multiple teams are working together, it might be a different story.

Multiple Teams Coordinating Work During Sprint

If you have 2–3 teams trying to coordinate work during a Sprint, some groups stagger their Daily Scrum events. For example, Team A, B and C hold their Daily Scrums 20 minutes apart. One person from each team (not the ScrumMaster) visits the other teams’ Daily Scrums to hear how the work will affect their own team, and to share how their team’s work will affect the others.

This is taken from the Large Scale Scrum approach and the arrangement is usually temporary. Teams determine in Sprint Planning which other teams they need to work with that Sprint and plan the coordination mechanism.

If there are more than 3 teams, some groups create a separate Scrum of Scrums. For more sources on multi-team Scrum see: Scaling

Tips for Remote Daily Scrum

• Kill off Outlook/Gmail/Slack/Teams so there are no distractions
• Camera on. Being able to see body language and facial expression goes a long way to reducing miscommunication.
• Good microphone. If team members are working remotely, the organization can afford to buy everyone a good microphone.
• Headphones or earbuds to reduce audio feedback.
• Remind everyone to display the Sprint Backlog.

Many of these types of things get baked into the team’s working agreements.

Can Daily Scrum Be Async?

What does an Async Daily Scrum look like: Slack thread, short video clip or some other update that doesn’t require people to be available at the same time. It gets used when teams are spread so far apart that they don’t have time in common.

The tradeoff: Daily Scrum goes from being about human interaction to reporting status updates. It kills off any opportunity for questions, context, seeing body language and human connection. Even worse, we lose the “oh, I can help there” moments. When I’m coaching a team, one of my measures of team health is how much collaboration gets sparked by Daily Scrum.

If you read other sources I’m supposed to provide advice now on how to conduct an Async Daily Scrum. The advice will be short, it’s an anti-pattern that disrupts teams.

Effective Daily Scrum is a skill that ScrumMasters develop over time. Learning to facilitate conversations that actually improve collaboration is one of the core competencies we develop in our Certified ScrumMaster training.

Related reading:

• Scrum by Example: Feeling Pain from Your Daily Scrum?
• Collaboration Over Work in Isolation
• Sprint Goals Provide Purpose
• The Humble Sprint Backlog

Updated April 2026