The Daily Scrum and the Sprint Review

The Daily Scrum belongs to the Developers

Fifteen minutes, every working day of the Sprint, at the same time and place to reduce complexity. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, adjusting the work planned next, and its output is an actionable plan for the next day. If the Product Owner or the Scrum Master are actively working on Sprint Backlog items they take part as Developers — the event is defined by who it is FOR, not by a guest list somebody polices.

That distinction is the whole of the classic scenario. A line manager starts attending, asks each Developer in turn what they did yesterday, takes notes for a weekly status report; the event drifts to twenty-five minutes and the Developers quietly stop mentioning problems. The failure is neither the manager standing there nor the overrun. It is that the event now produces a performance record, and nobody surfaces an impediment in a meeting whose output is a performance record.

So the fix is not to ban attendees, and it is not to make the same status meeting faster by shortening everybody's answers. It is to coach the room back to the event's purpose, and the test of whether that worked is whether the Developers leave with a plan for the next day that differs from the one they walked in with.

Scrum names the purpose and then stops

What the framework fixes about the Daily Scrum is short: how long, how often, who it is for, and what it must achieve. The structure is left to the people doing the work. The Developers may select whatever techniques they want provided the event stays focused on progress toward the Sprint Goal and produces that actionable plan, so a five-minute walk of the board that discusses only the items putting the Sprint Goal at risk is a perfectly good Daily Scrum — and finishing in five minutes is fine, because fifteen is a maximum.

The three questions — what did I do, what will I do, what is blocking me — are a technique many teams use and the 2020 framework does not require them. A team can answer all three impeccably and inspect nothing whatsoever about the Sprint Goal, which is exactly what happens when the round-the-room habit outlives the reason anybody adopted it.

Nor is the Daily Scrum the only moment at which the plan may move. The Developers often meet through the day for the more detailed conversations about re-planning the rest of the Sprint's work. The Daily Scrum is the point at which that adaptation is guaranteed to happen, not the point at which it becomes permitted.

The Sprint Review is a working session

The Sprint Review inspects the outcome of the Sprint and determines future adaptations. The Scrum Team presents the results of its work, everybody reviews what has changed in their environment, and on that basis the attendees collaborate on what to do next — which regularly means adjusting the Product Backlog to meet new opportunities. The Guide names the trap in the same breath: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation."

A polished deck, fifty minutes of talking, two questions, warm compliments and a Product Backlog that is unchanged afterwards is the failure the exam describes. No timebox was breached — fifty minutes sits comfortably inside four hours — and nobody was rude. The tell is the unchanged backlog: an inspection that produced no adaptation was a broadcast, and the scenario is built so that every other candidate explanation is factually wrong.

Two things the Review is not. It is not where the next Sprint gets planned; that happens at that Sprint's own Sprint Planning, and the Review shapes what the next Sprint should be ABOUT rather than how its work will be done. And it is not where the team decides how to improve the way it works — that is the Sprint Retrospective, which follows the Review and concludes the Sprint.

Presentation is not permission

An Increment may be delivered to stakeholders before the end of the Sprint, and the Guide states the consequence without hedging: "The Sprint Review should never be considered a gate to releasing value." Work that met the Definition of Done on a Tuesday can be in customers' hands on the Tuesday, and holding it back so that stakeholders see it at a meeting first delays value for no empirical benefit at all.

Two questions that look alike have different owners, and separating them settles most of this family of questions. Is it Done is answered by the Developers, against the Definition of Done. Should it go out is a decision about value, and value decisions belong to the Product Owner. There is no acceptance ceremony, no sign-off and no approval step anywhere in Scrum: an item either meets the Definition of Done or it returns to the Product Backlog for future consideration.