The Daily Scrum is the 15-minute huddle where the developers come together to check if they're on track to meet the Sprint goal. It's been around since the first version of Scrum, and while description of Daily Scrum and the questions asked during the meeting have changed over the years, its purpose has remained the same.

In the older description of Daily Scrum, it specifically started with saying “Each Scrum Team meets daily for a 15-minute status meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains: (formatting of the word "status" and "explains" are mine)

1. What have you accomplished since the last meeting?
2. What are you going to do before the next meeting?
3. What obstacles are in your way?

And then in the later part of the section it stated “The Daily Scrum is not a status meeting.” It also stated “The intent is to optimize the probability that the Team will meet their Goal. This is a key inspect and adapt meeting in the Scrum”

As you can see the intent of the Daily Scrum from the earlier version of the definition of Scrum is to inspect if the team can meet the Sprint Goal or not.

​In 2011, the language changed a little bit, I think, towards the worse side. The change in the first line looked really good though. It stated “The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.” The status part is gone and it is not for the Scrum Team but for the Development Team. However, the questions remained the same. But the worse thing was what it said in the later part. It stated “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint.” Doesn’t that sound like a status meeting every day to report not only to the Product Owner but to the Scrum Master too?

In 2013, the description of Daily Scrum got much better. It still had those three questions. But the questions were tweaked to emphasize the team meeting the Sprint goal.

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Also disappeared the statements that sounded like the developers are “explaining” to the Product Owner and Scrum Master on a daily basis.

In 2020, the three questions were dropped altogether.  This was a good move to make the framework in line with Scrum being a minimally sufficient framework. Removing this prescriptive language finally recognized that the three questions are not the only way to accomplish what we want to accomplish in Daily Scrum. Another welcome change is that, the guide do not say, as in the previous versions,  that “The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work”. It may sound like developers need to have scheduled meetings in order to collaborate.  In the latest version the statement is “The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.” This is line with the intent that the Developers are a team and they collaborate all the time.

The good thing is that the purpose of the Daily Scrum never changed. It has always been “ to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”

It is a good thing that the Scrum Guide itself continued to evolve - by inspecting and adapting and making changes. Unfortunately the world haven’t changed. I still meet a lot Scrum practitioners who think that the Scrum Master is to ask those three basic questions and that the Developers are to answer those so that Scrum master can make decisions - just like a status meeting with a team lead or a manager - every day, while standing up, possibly even before having a coffee. That sounds horrible. Shouldn’t we treat our team members as responsible adults? These people voluntarily signed up to work toward the spring goal, supposed to be self organizing.  Hum.... what did the Agile Manifesto say?

Here is the result of a survey conducted on LinkedIn (concluded on Jan 4, 2023). According to the 168 people who voted, it seems that most people believe that the Scrum Master is responsible for tracking the progress of the team's work.

The Scrum Guide does not clearly say who should be responsible for this task. But there are some indications.  Here are some quotes from The 2020 Scrum Guide ™¹

Under the Scrum Team Section
"Scrum Team is structured and empowered by the organization to manage their own work." It also says "The entire Scrum Team is accountable for creating a valuable, useful increment every sprint."

Under the Developers Section
The Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.

Under the ScrumMaster Section
The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in self-management and cross-functionality

(This is the only part in the ScrumMaster section that says anything about planning or managing the plan.)
Under Daily Scrum Section
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Given these responsibilities outlined in the Scrum Guide, it seems that we could go with either Scrum Team or Developers. There is no indication that the ScrumMaster or Product Owner be responsible for tracking the progress during the sprint.

Do you see this differently? Apparently 45% of you do. I would love to hear about your reasoning. Please comment or send me a message. 

My personal take is that, the developers should be primarily responsible for tracking the progress of their work. However, the ScrumMaster can certainly offer assistance and support in this task. The problem arises when the ScrumMaster is the only person concerned about whether the team will meet the Sprint goal, while the team members themselves do not seem to care. To me this means that ScrumMaster is not effective in coaching which the real responsibility. Instead of coaching the team, they are choosing to manage it themselves. Note that the Scrum Guide explicitly says that the ScrumMaster is responsible for coaching the developers in self management.

It’s like my parenting. I have tried so many ways to get my kids to clean up the mess that is left in the kitchen after they cook the simplest of meals. But they don’t, and I end up cleaning it up myself. Should I keep cleaning up after them? As a parent, I have some easy tools that I can use as in money, privileges, etc. But as a ScrumMaster, I don’t have any of that. So it is difficult to do. What have I seen? More often than not, it is an organizational problem. Based on the conditions that the Developers are working in, it is not always possible to care about the team’s progress at large even if they care. They are not empowered to do so or there is no incentive to do so. In some cases, individuals may be working on 5 other projects and they barely get time to do the work that they are an expert on; let alone looking at what the team at large needs to meet the Sprint goal. A ScrumMaster’s Job is do the investigation in the organization and try changing the conditions in said organization.

Have you encountered a situation where team members were not concerned about meeting the Sprint goal? If so, what did you do to address this issue?

I would love to hear your thoughts and experiences on this topic.
References

1. https://scrumguides.org/scrum-guide.html