All in this together

Daily Scrums explained

Steffan Surdek

Forget boring, stuffy meetings: this is your team’’s daily synchronization tool.

Before I tell you what the meeting is about, let me begin by telling you that, contrary to popular belief, the daily scrum meeting is not a status report meeting. If your team merely stands around in a circle, each reciting what they did yesterday and what they will do today while looking straight at the Scrum Master, then you are the kind of team I am talking about!

The daily scrum is in fact about allowing team members to synchronize on a daily basis to coordinate their efforts for a sprint. Notice that when you build a sprint backlog, you identify the tasks and the number of hours for each of these tasks but you do not identify target end dates or build Gantt charts for dependencies. The daily scrum is how teams synchronize and communicate throughout the sprint.

Why should the meeting occur every day, at the same time and in the same location? Because sometimes routine can be your friend. What you really want is for John or Julie to walk into the office in their zombie-like state, automatically grab their coffee and find their way to the meeting. You want the meeting to become a habit for everyone.

Who should attend?

Teams often ask me who should attend the daily scrum meeting. Team members are mandatory attendees, while the Scrum Master and Product Owners are optional attendees. Ideally team members will self-organize and run the meeting on their own, but initially the Scrum Master facilitates the meeting to make sure the team gets on track.

One team I collaborated with decided to name a different meeting facilitator every day of the week. This allowed the team to take full ownership of the meeting instead of the Scrum Master.

Focus on synchronization

Sprint backlogs do not contain due dates so teams need some form of mechanism to work on their dependencies during a sprint. The most effective and useful way to run your daily scrum meeting is to focus the team on answering three daily scrum questions with a goal of synchronizing their efforts and making sure they will meet their sprint goal.

The not so subtle distinction between the daily scrum as status report instead of a synchronization meeting begins with how the team answers the following three questions:

  • What did I do yesterday?

  • What did I do today?

  • What are my blockers?

When team members talk about what they did yesterday, they provide cues to others with a dependency on their tasks. For a simple case, a developer pointing out all coding tasks related to a specific feature are complete signals to the tester that they can begin testing it.

When a team member talks about what they will do today, they are essentially making a verbal commitment to the team. Other team members will know what this person is working on and if they are focusing on work relevant to meeting the sprint goal. Similar to the previous example, knowing ahead of time what another team member is working on may help you better plan your day. For example, if a developer expects to finish the work on a feature today, a tester may decide to focus on finishing the relevant test cases for this feature.

Task boards increase visibility

Just answering the three questions may not be useful if the team cannot picture their progress during the sprint. Looking at the sprint task board during the daily scrum meetings is a simple way to get this visibility.

Some teams manually build and uphold their sprint task boards (see figure 1 below) using sticky notes and tape on a wall or a rolling whiteboard they can move around, while other teams use electronic agile planning tools. Using the task board view of an agile planning tool may be more suitable for distributed teams.

Figure 1: Sprint task board.

I find that answering the three questions in front of a whiteboard while moving tasks and updating hours in real time helps make the progress come alive. As an alternative, some teams I know have a rule stating that team members need to update the task board at least five minutes before the start of the meeting.

In either case, I usually ask team members to go up to the task board and point to the tasks they are alluding to so the team understand what they are discussing. Having people point also helps the team make sure everyone is focusing on the most important user stories and shows people are doing work relevant to the sprint.

Notice the unsaid blockers

When team members are answering the three questions, it is good practice to listen for the blockers people arenot directly mentioning. I often see situations where team members say they have no blockers, but their answers to the two other questions indirectly mention many blockers.

For example, someone discussing what they did yesterday may talk about the unexpected support issues that keep coming up. Unmanaged, these support issues become blockers. Someone else may talk about a weekly internal committee meeting they need to attend that is eating away some of their time.

A more subtle form of unsaid blocker occurs when people keep putting new tasks in progress because they are waiting for answers on other tasks. To notice these, the team also needs to pay attention to the work already in progress. These unsaid blockers should produce questions and become conversation points for the team.

Getting long Daily Scrums under control

Effective daily scrum meetings should last no longer than fifteen minutes. For many teams, respecting this time limit is a big challenge but it is important to respect the time box or team members will lose interest in the meeting. Teams larger than five to nine people may decide that fifteen minutes is not suitable for them and may opt for a slightly longer time box.

When you see your team having design discussions or trying to problem solve, the best approach is to call a separate meeting after the daily meeting. Invite only key people to this discussion to not waste the time of all team members.

If the meetings are running long because people are talking too much, one solution is to use a timer. I have two variants on this technique: the first method is to time the meeting and stop at fifteen minutes, no matter what. You can be sure the people who did not have time to speak will get upset and will want to speak first the next day. The other method is to divide the meeting time equally between all participants; when I use this, I interrupt people when their time is up.

The importance of useful answers

Another challenge of daily scrums is when people provide answers that are useless to the three questions. You can see one of my favorite examples below. As you can see, the answers are completely useless to the team. The team would get much more value if the person would take the time specify which defects he is talking about.

“Hi Gang… What did I do yesterday? Well, I fixed some defects… Today, I think I am going to fix more defects… What is blocking me? Well… If only I did not have so many defects to fix!”

When team members (not just the Scrum Master) feel the answers are useless, they should not just let it slide, but ask more pointed questions. In these situations, I find humor works well, and I will make a joke such as “Joe, that sounds both nice and mysterious… Could you please tell us more?” to get more information.

Peer pressure and visibility are important parts of the daily scrum. When you tell the team what you will work on today, you are making a verbal commitment to the team. Team members that depend on your work expect you to complete what you said you would do today so their own work can move forward tomorrow.

Keeping an eye on the goal

Just blindly answering the three questions, even with the sprint task board in front of you, is rather useless if the team is not keeping an eye on delivering on their sprint goal. One of the last questions I like to ask at the end of the meeting is whether the team feels they will meet their sprint goal.

When the team does not feel confident, members may need to reorganize their work to allow them to complete the high priority pieces while letting others drop to the next sprint. The team needs to discuss such decisions with the Product Owner.

Learning in the last days of a sprint that the team will not deliver the planned work is a powerful sign the team is not keeping track of the spring goal.

Preserving transparency and focus

One common issue that I see is when certain team members refuse to update their estimates of time remaining. This causes situations where someone has an everlasting thirty-hour task, even though they work on it every day. Ideally, tasks should be no longer than a day or two to allow the team to see progress.

In such situations, the best approach is to encourage that person to break up tasks in smaller blocks at the sprint planning meeting to allow delegation to others. During a sprint you may want to ask the person to list the remaining work and create tasks for each work item. Once you have these tasks work on getting proper estimates.

Be aware some people refuse to break down their work into smaller tasks because they are uncomfortable with the visibility it provides. For example, if they estimate five hours and it takes seven or eight instead, they may look bad. When facing these people, you may need to have some separate one-on-one conversations to hear their concerns and address the issue.

Another focus-related challenge is of team members with five tasks already “in progress” on the task board that feel an overwhelming need to add yet another task in that column. During the meeting, the team needs to ask this member about the status of the other tasks currently in progress. Are some of these blocked? Are some of these done but not yet moved to the “done” column? If they are still in progress, they need to focus on completing their work before starting something new.

Making sure everyone pays attention

When many people talk at once or side conversations occur, it can cause serious communication challenges. When side conversations occur, my preferred approach is stopping the person currently speaking to the group so that everyone can focus on listening to the side conversation. I always find it interesting how putting people in the spotlight encourages them to self-discipline and stop their conversation.

For teams where many team members chronically speak at once, I occasionally use a talking stick, where only the person holding stick may speak. This forces the team to have only one speaker at a time. In one company I worked with, I used a plastic microphone as a talking stick with the teams I coached. I saw other teams use a ball they toss to one another or a dog squeaky toy as their preferred speaking permission tool.

Other ways people stop paying attention is by fiddling around on their cell phones or staring into nothingness. The best way to get their attention is by calling on them to speak next or using humor to draw them back in. The most direct way to address this is literally calling them out for not paying attention.


Remember the goal of the daily scrum meeting is to allow the team to coordinate their efforts and ensure they are on track to meet their sprint goal. The meeting is not meant or feel like a daily status report meeting.

When team members answer the question “what am I doing today?” they are implicitly making a verbal commitment to their team. Peer pressure (i.e. the team asking why someone did not meet a commitment) is another important aspect of the daily scrum. Team members should feel comfortable challenging one another in a healthy way about their deliverables.

The team should be able to do a daily scrum meeting with or without the Scrum Master present. This is part of the team taking ownership of their software development process. The Scrum Master should actively encourage the team to step up and own this meeting.

Daily scrums are an important part of the sprint cycle because they help the team collaborate and plan on a daily basis. Keeping them interesting and effective will enable your team to stay focused and regularly deliver on their sprint goals.
Steffan Surdek is a senior consultant and agile coach at Pyxis Technologies. Steffan has worked in IT for over eighteen years in collaboration with many distributed teams around the world. In the last few years, Steffan was an agile trainer and coach in large companies such as IBM and the TD Bank Group. He speaks at many conferences and user groups about agility with distributed teams. Steffan is co-author of the book 'A Practical Guide to Distributed Scrum' written in collaboration with the IBM Scrum Community. He blogs on his websites and

Inline Feedbacks
View all comments