The Daily Scrum has a complicated reputation. Teams that use it well say it is the most valuable fifteen minutes of their day. Teams that use it badly say it is a pointless ritual where everyone reports what they did yesterday to a Scrum Master taking notes. Both experiences are common. The difference is almost entirely in how the event is understood and facilitated.

What it is for

The Scrum Guide's definition is clear: the Daily Scrum is an event for the Developers to inspect their progress toward the Sprint Goal and adapt the Sprint Backlog as needed. Not to report to the Scrum Master. Not to update stakeholders. Not to flag impediments for someone else to handle. To inspect progress and adapt the plan.

This is a subtly different framing from how most teams run the meeting. "Inspecting progress toward the Sprint Goal" means the team starts by asking whether they are on track to achieve what they set out to achieve — not just whether individual tasks are being completed. A team that is completing its tasks but drifting away from the Sprint Goal has a problem that the three-questions format alone will not surface.

The three questions — and why they are optional

The 2020 Scrum Guide removed the explicit three-question format (what did I do yesterday, what will I do today, what is blocking me) as a requirement. The Developers can structure the event however serves best as long as it produces a plan for the day and surfaces necessary adjustments.

This is worth noting because many teams treat the three questions as the definition of the Daily Scrum rather than as one useful template. In practice, teams that have been doing Scrum for a while often find that walking the Scrum Board — discussing items from right to left, focusing on what is closest to done — produces more useful conversations than individual round-robins. The board-walk format keeps attention on the flow of work rather than on individual activity, which aligns better with what the event is designed to achieve.

What makes it work

Several disciplines consistently improve the value of Daily Scrums:

Keep it to fifteen minutes. This is a timebox, not a default. If the Developers can inspect progress and adapt the plan in ten minutes, finish in ten minutes. If the conversation is still productive at fifteen minutes, it should continue — but in a follow-up session with the relevant participants, not in the Daily Scrum where it will tax the patience of everyone for whom it is irrelevant.

Prepare in advance. The Daily Scrum works best when team members have thought about the three core questions before the event. Updating the Scrum Board, noting impediments, and considering the day's work before the meeting keeps the meeting focused rather than exploratory.

Let the Developers run it. The Daily Scrum is for and by the Developers. The Scrum Master facilitates if needed but does not conduct the meeting. The Product Owner can attend but does not typically speak unless specifically invited. When the meeting is run by the Developers for their own benefit, it is more likely to produce the genuine commitment and shared understanding that the event is designed to create.

Connect it to the Sprint Goal. The Sprint Goal is the thing the Daily Scrum should be tracking toward. If the team never mentions the Sprint Goal in their Daily Scrum, the event is producing coordination but not strategic alignment. Asking "does what we have planned for today move us toward the Sprint Goal?" is a simple addition that significantly changes the quality of the conversation.

What it is not

The Daily Scrum is not a place to resolve problems. Problems that surface during the meeting should be noted and addressed in a follow-up conversation involving only the relevant people. Taking twenty minutes to debug an issue while the rest of the team waits is the most common way for the Daily Scrum to lose its usefulness and acquire its reputation as a pointless ritual.

Done well, the Daily Scrum is one of the most powerful feedback loops in the Scrum framework. Done badly, it is fifteen minutes of noise. The difference is usually a matter of habit and facilitation rather than any structural complexity.