Who is the Daily Scrum for in Scrum, and what must it produce?
answer
- The event has exactly one owner
- Its output is a plan, not a report
- Fifteen minutes, every working day
- Progress is measured against the Sprint Goal
basics
~20 sThe Daily Scrum belongs to the Developers. In fifteen minutes they inspect progress toward the Sprint Goal and produce an actionable plan for the next working day, adapting the Sprint Backlog. It is not a status report to a manager.
solid answer
~50 sScrum makes the **Developers** accountable for the Daily Scrum, and the event's output is a plan rather than a report. In fifteen minutes, at the same time and place every working day, the Developers inspect how much progress they have made toward the **Sprint Goal** and adapt the **Sprint Backlog** to whatever they now believe is the fastest route to it. The framework prescribes no internal structure: the three familiar questions are one option among many, and a team may run the event however it likes provided the result is the day's plan and the focus stays on the Sprint Goal. The Product Owner and Scrum Master may attend, but participate as Developers only when they are working on Sprint Backlog items themselves. Impediments surfaced here are raised in the event and resolved outside it, so the fifteen minutes stay a re-planning event.
go deeper
Recall that the Daily Scrum is fifteen minutes, happens every working day, and belongs to the Developers. Know that its purpose is planning the day ahead rather than reporting yesterday to anybody.
Explain the inspect-and-adapt pair: progress toward the Sprint Goal goes in, an adapted Sprint Backlog comes out. Be ready to say that the three familiar questions are optional rather than prescribed by the framework.
Show how you recognise a drifted event and pull it back - Developers addressing one listener, design debates eating the fifteen minutes, no plan ever changing. Talk about what you actually did, not what the framework says.
Own the harder version: what you do when senior management treats the Daily Scrum as their reporting channel. Be ready to describe the alternative you offered them and why this event was the wrong place for it.
## Whose event it is The Daily Scrum is the **Developers'** event. Scrum makes them accountable for it, and almost everything else about it follows from that single fact: the audience is the people who will do the work today, the subject is what they will do, and the output is a decision rather than an account. The Product Owner and the Scrum Master may be present, but they participate as Developers only if they are working on Sprint Backlog items themselves. That ownership is the difference between an event that keeps costing fifteen minutes and one that keeps earning them. Once the Developers begin addressing their sentences to whoever else is in the room - a manager, a delivery lead, the Scrum Master - the event quietly changes purpose. Nobody announces the change and the words sound the same, but the room has started producing an account of yesterday instead of a plan for today. ## What the event is meant to produce Two things have to happen inside the fifteen minutes: 1. **Inspection.** The Developers look at progress toward the **Sprint Goal**, not at a count of tasks closed. The subject is whether the goal is still reachable and what today's evidence says about it. 2. **Adaptation.** They change the **Sprint Backlog** accordingly and leave with an actionable plan for the next working day. Someone swaps what they intended to pick up, two people pair on the item that is at risk, an item nobody can move gets named as blocked. If the event ends and nothing about the day's plan differs from what each person already intended before walking in, the inspection produced no adaptation and the event was decorative. ## What Scrum prescribes, and what it leaves open | Prescribed | Left to the Developers | | --- | --- | | Fifteen minutes | The format and the running order | | Every working day of the Sprint | Whether anyone facilitates it | | The same time and the same place | Whether the three familiar questions are used at all | | Focus on progress toward the Sprint Goal | How impediments get recorded and chased | | Held by and for the Developers | Whether the Sprint Backlog is walked by item or by person | The three questions many teams recite - what did I do, what will I do, what is in my way - are one possible structure and are not required by the framework. A team that produces a good plan by walking its Sprint Backlog item by item, or by talking only through the two items that are at risk, is running the event correctly. The fixed time and place exist to remove the daily cost of arranging the event, not as ritual. ## Where the other accountabilities fit - The Scrum Master makes sure the event happens, stays productive and stays within fifteen minutes, coaching rather than chairing it. - The Product Owner is welcome and is often useful when a scope question surfaces, but the event is not a checkpoint held on their behalf. - Anyone else may observe; nobody else may convert the event into their own update. - Impediments named here are chased outside the event, usually straight afterwards and with only the people involved. - The event still happens when the Scrum Master is away, because it never belonged to the Scrum Master. ## Symptoms that the event has drifted - Developers speak to one listener rather than to each other. - The content is a list of completed tasks with no reference to the Sprint Goal. - The event routinely overruns because design discussions are held inside it. - Absent people are covered for so that the record looks complete. - Nothing in the day's plan ever changes as a result of the event. - The event is skipped when one particular person is on leave, which reveals who the team thinks owns it. Every one of those has the same repair: return the event to its purpose. The Developers say what they now believe about reaching the Sprint Goal, change the plan where the evidence points, carry the long conversations outside with the people who need to be in them, and finish. ## Why interviewers keep asking it The Daily Scrum is the event most often distorted in practice, so the question separates a memorised definition from lived experience cheaply. A candidate who says fifteen minutes and the three questions has read the summary. A candidate who says the Developers own it, the output is a plan, and here is how I noticed ours had turned into a report has run one.
- The Scrum Master and the Product Owner both want to attend. Is that allowed?Yes, they may attend, and they participate as Developers only when they are working on Sprint Backlog items themselves. The risk is not attendance but gravity: if the Developers start addressing their update to whoever else is in the room, the event has turned into a report and stopped producing a plan. Watch who people look at while they speak.
- Someone raises a design disagreement that will clearly take twenty minutes. What do you do?Name it, name who needs to be in the discussion, and take it outside the fifteen minutes - usually straight afterwards. The Daily Scrum exists to produce the day's plan, and a design argument spends the whole event on a subset of the people standing there. Scrum expects impediments and detailed discussions to be handled after the event.
- Half the Developers work in a distant time zone and cannot all meet daily. What now?The framework expects the event every working day at a consistent time and place; the shape inside that is the team's choice. A written thread that everyone updates before an agreed cut-off can satisfy the purpose if it still yields a shared plan and surfaces impediments the same day. What it must not become is a log of yesterday that nobody reads.
It is the huddle a shift crew calls before the next leg of work: the point is agreeing who does what next, not telling a supervisor what happened yesterday.
saying these in an interview costs you the question
- Describes the event as a status update for the Scrum Master
- Insists the three familiar questions are mandated by Scrum
- Uses the fifteen minutes to solve technical problems in depth
- Reports tasks completed instead of progress toward the Sprint Goal
- Assumes the Scrum Master must run the event every day