The Daily Scrum: A 15-Minute Planning Event, Not a Status Report
The Daily Scrum is a 15-minute planning event in which the Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog; its output is an actionable plan for the next day, not a report. The post covers why the three questions were removed in 2020, a format that walks the board from right to left and looks at item age, practices for remote and hybrid teams, and the traps of reporting to managers, problem solving and overruns.
Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland); as of November 2026 it is still the current official version on scrumguides.org. References on the Kanban side are based on Scrum.org's Kanban Guide for Scrum Teams.
Guess First
Bookstore's Daily Scrum is at 09:30. Kerem opens the meeting and hands out turns; everyone tells what they did yesterday, what they will do today and whether anything is blocking them. After each person, Selin asks "when will this be done?" and copies her notes into the weekly report. When Ayşe starts describing a bug in the shipping company's API (Application Programming Interface), Emre and Can join in and the topic takes ten minutes. The meeting averages 28 minutes.
According to the 2020 Guide, how many problems are in this picture? And which is the most critical: going past 15 minutes, the three questions, or something else? Write down your guess; the answer is in the first two sections.
The Real Purpose of the Daily Scrum
The Guide states the purpose of the Daily Scrum in one sentence: to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. So the Daily Scrum is a planning event. Its output is not a report but an actionable plan for the next day.
Everything else follows from that purpose. The Daily Scrum is a 15-minute event for the Developers. 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. The Developers can select whatever structure and techniques they want; the only condition is that the Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. According to the Guide, this focus also improves self-management.
That is why the most critical problem in the Bookstore picture is not the duration but who people are talking to. Everyone reports to Selin and Kerem, not to each other. At the end of the meeting nobody's plan changes; only Selin's report gets updated. That is inspection that never turns into adaptation, pointless inspection in the Guide's words.
A Short History of the Three Questions
"What did I do yesterday, what will I do today, is anything blocking me" became so tied to Scrum that most teams think they are the definition of the Daily Scrum. The Guide's revision history tells a different story. The 2013 version turned the questions from the individual to the team: "What did I do yesterday that helped the Development Team meet the Sprint Goal?" and so on. The same revision explicitly noted that the Daily Scrum is a planning event and is too often seen as a status event. The 2017 version left the structure of the meeting to the Development Team and gave the questions only as "an example of what might be used". The 2020 version removed them entirely.
The reason for removing them, in the words of the revision notes, was to bring the Guide back to being a "minimally sufficient" framework and to soften prescriptive language. The three questions are not forbidden; but when they force a round of turns, the Daily Scrum easily becomes a ritual where everyone reports in sequence. At Bookstore, Ayşe's sentence "yesterday I worked on the shipping API, today I'll keep working on it" was repeated every morning, and nobody noticed that the item had been sitting in the same column for five days.
Walking the Board from Right to Left
The Bookstore team changed the format. They now go through the items on the board rather than through people, starting from the column closest to Done. The logic is simple: the most valuable work is work that is about to finish; finishing half-done work before starting something new means ending the Sprint with three finished items instead of five half-finished ones. The idea comes from Kanban; Scrum.org's Kanban Guide for Scrum Teams suggests looking at flow in the Daily Scrum, that is, at how work moves across the board. The board at 09:30:
| Column | Item | Age (days) | Note |
|---|---|---|---|
| Test | Delivery date time zone bug | 2 | Deniz can close it today |
| Code Review | Create return request endpoint | 3 | Waiting for review for two days |
| In Progress | Return request Angular form | 2 | Depends on the endpoint |
| In Progress | Shipping return label integration | 5 | Blocked: test account not yet received from the shipping company |
| In Progress | Support panel list screen | 1 | Emre just started |
Walking right to left, the conversation naturally goes to the right places. For the time zone bug there is one question: does it finish today? Yes. The endpoint has waited two days for review and Zeynep's form depends on it; instead of continuing with the support panel, Emre offers to do the review first. The shipping integration has been in the same place for five days; Kerem will call the contact at the shipping company about the test account today, and while waiting Ayşe will write a test stub that mimics the label request. Twelve minutes produced three plan changes, and none of them came from "what did I do yesterday".
Item age (work item age) is the most useful number here. It shows how long an item has been on the board and raises the alarm on day three, not at the end of the Sprint. How age, WIP (Work in Progress) and the other flow metrics are calculated and interpreted is in the Kanban series post "Flow Metrics: WIP, Throughput, Work Item Age and Cycle Time"; practices for actively dealing with aging items are in the same series' post "Actively Managing Flow in Kanban: Blockers, Aging and Flow Reviews".
15 Minutes and After
15 minutes is not a target but an upper limit. The Guide says the Daily Scrum improves communication, identifies impediments, promotes quick decision-making and consequently eliminates the need for other meetings. That is why keeping it short matters: when problem solving enters the meeting, four people who have nothing to do with the problem wait for ten minutes.
Bookstore's solution is an "after" list. If a topic would take more than two minutes in the Daily Scrum, its name goes on the list and only the people involved stay once the event is over. The shipping API bug is now a twenty-minute conversation between Ayşe, Can and Emre at 09:45. The Guide says explicitly that the Daily Scrum is not the only time Developers can adjust their plan; they often meet throughout the day to re-plan the rest of the Sprint's work.
Whose Meeting Is It?
The Daily Scrum is the Developers' event. The Scrum Master's accountability is to ensure the event takes place, is positive and productive, and stays within the timebox; not to run it or hand out turns. At Bookstore, Kerem facilitated for the first two weeks, then facilitation moved to a weekly rotation among the Developers and Kerem started attending only as an observer.
The Product Owner's position in the Guide is clear: if they are actively working on an item in the Sprint Backlog, they participate as a Developer. Selin's "when will this be done?" question, however, was changing the direction of the meeting; the Developers began talking to her instead of each other. Selin no longer attends the Daily Scrum; she can see the board whenever she wants and asks her questions after the event. The place of stakeholders in the Daily Scrum is not defined in the Guide; if they attend, keeping the meeting from turning into a reporting session is up to the Developers and the Scrum Master.
The Daily Scrum in Remote and Hybrid Teams
At Bookstore, Can works from Izmir and Deniz works from home two days a week. Practices that work in remote and hybrid setups:
- Everyone joins from their own computer; if the people in the office gather in front of one screen, the remote people miss the conversation.
- The board is shared on screen and walked from right to left; items, not people, drive the conversation.
- The time is fixed inside the widest overlapping window; the remote equivalent of the Guide's "same time and place" is the same link at the same time.
- A written pre-note can be used but does not replace the event; three-line updates in Slack do not answer each other, so the plan does not change either.
- A separate room is opened for "after" topics; everyone is free at the end of the first 15 minutes.
A fully asynchronous Daily Scrum makes the purpose of the event the Guide describes, inspecting together and adapting the plan together, harder to achieve. For teams spread across time zones this is a trade-off: if the overlap is very short, the team can work synchronously on some days and in writing on others; but if more and more written days end with "nobody changed anything", that is a signal.
In Production: What to Watch
Bookstore looks at three things to see whether the Daily Scrum works. First, does anything change in the Sprint Backlog after the event? If there are no plan changes for a whole week, either everything is going perfectly or no inspection is happening; the former is rare. Second, the age of blocked items: how many days an item stays blocked shows how quickly the impediment is handled in the Daily Scrum. Third, duration: if the average goes past 15 minutes, problem solving is leaking into the Daily Scrum.
As the team grows, the Daily Scrum struggles too. In a ten-person team, walking the board may not fit into 15 minutes; that is usually a sign the team should split. If several teams work on the same product, cross-team dependencies need extra coordination; Nexus defines this as the Nexus Daily Scrum.
Common Pitfalls
Reporting to a manager. Holding the Daily Scrum so that someone can collect information, rather than for the Developers' own plan, is the first symptom of what Ron Jeffries calls "Dark Scrum": Scrum's events are used to control the team instead of managing the team's work. The tenth post of the series covers this anti-pattern in detail.
Turning into a problem-solving discussion. When a technical problem is tackled in the middle of the meeting, the timebox is blown and the people not involved wait. The "after" list is the cheapest fix.
Conversation disconnected from the Sprint Goal. Everyone describes their own item, but nobody asks "at this rate, will the Sprint Goal hold?". Asking that question openly once a week gets scope discussed with the Product Owner early.
Treating 15 minutes as mandatory and talking for exactly 15 minutes every day. If nothing on the board has changed, a six-minute Daily Scrum is perfectly valid.
A Small Experiment
★☆☆ In your next Daily Scrum, time it and count the plan changes that come out of it. Note both numbers for a week.
★★☆ For one week, run the Daily Scrum by walking the board from right to left instead of person by person. At the end of the week, compare the average age of blocked items with the previous week.
★★★ For one day, note who talks to whom in your team's Daily Scrum: draw a line for each remark to the person it is directed at. If most lines converge on one person (the Scrum Master, the Product Owner, a manager), discuss with the team in the Retrospective whom the event is really serving.
The Daily Scrum inspects the plan every day; but how do we know that what comes out at the end of the Sprint is really "done"? In the next post we move to the Increment and its commitment, the Definition of Done, and show how Bookstore's .NET and Angular team checks a concrete Definition of Done automatically in CI (Continuous Integration).