8.2 The Daily Scrum & Sprint Review as Empirical Feedback Loops
Key Takeaways
The Daily Scrum is a 15-minute internal replanning event exclusively for the Developers to inspect progress toward the Sprint Goal and adapt their 24-hour tactical plan.
The 2020 Scrum Guide removed the 'three questions'; Developers may use any structure that focuses on progress toward the Sprint Goal, such as walking the board right to left.
The Scrum Master does not chair or run the Daily Scrum, but ensures it happens, stays within the 15-minute timebox, and coaches Developers to maintain empirical focus and self-management.
The Sprint Review is an active, collaborative working session—not a one-way slide-deck demonstration—where the Scrum Team and key stakeholders inspect the Increment, evaluate market trends, and adapt the Product Backlog.
Excluding skeptical or demanding stakeholders from the Sprint Review destroys transparency and robs the Product Owner of vital feedback needed to optimize product value.
8.2 The Daily Scrum & Sprint Review as Empirical Feedback Loops
Note
The Daily Scrum and the Sprint Review represent the two primary inspection and adaptation feedback loops of Sprint execution: the Daily Scrum operates at the tactical 24-hour horizon for Developers, while the Sprint Review operates at the strategic macro horizon with stakeholders.
The Daily Scrum: A 15-Minute Tactical Replanning Session
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It is a focused, 15-minute event held at the same time and place every working day of the Sprint to reduce operational complexity.
Exclusivity for the Developers
A critical distinction tested on the PSM II assessment is that the Daily Scrum belongs exclusively to the Developers. It is not a management check-in, an executive briefing, or a project reporting session. While the Scrum Master and Product Owner may attend, they do not participate unless they are actively executing work as Developers on items in the Sprint Backlog. Outside stakeholders, functional managers, and project coordinators may not participate, interrupt, or direct the discussion.
Moving Beyond the Obsolete "Three Questions"
Earlier Scrum Guides described three questions for the Daily Scrum; the 2017 edition offered them as an example structure the Development Team might use:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
While well-intentioned, this structure fostered widespread organizational dysfunctions. Across countless teams, the event degenerated into an individualistic roll-call where developers robotically recited ticket IDs and looked at the Scrum Master as if reporting for attendance. Recognizing this failure, the 2020 Scrum Guide eliminated the Three Questions entirely.
Today, Developers may choose whatever structure and techniques they prefer, so long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. Mature teams utilize dynamic facilitation techniques:
- Walking the Board (Right-to-Left): Rather than going person-by-person, the team inspects the Sprint board starting with items closest to the "Done" column. The focus is on clearing bottlenecks and pulling nearly-done work across the Definition of Done before starting new items ("Stop starting, start finishing").
- Swarming on Blockers: When a developer highlights a difficult defect or architectural snag, team members immediately volunteer to pair-program or mob on the issue, prioritizing collective flow over individual utilization.
- Replanning the Next 24 Hours: The conversation concludes with a clear, updated tactical plan: who is collaborating with whom, what dependencies are being resolved, and what concrete progress toward the Sprint Goal will be achieved by tomorrow.
Tip
Apply the "16th-Minute Rule": If two Developers begin debating a nuanced technical implementation detail, database schema design, or code refactor during the Daily Scrum, coach them to note the issue and defer the technical discussion to a breakout immediately following the 15-minute timebox. Only the interested engineers need remain for the breakout.
Scrum Master Facilitation Stance at the Daily Scrum
The Scrum Master is accountable for ensuring that the Daily Scrum takes place, that it remains within the 15-minute timebox, and that Developers understand how to conduct it effectively. However, the Scrum Master does not run, chair, or host the meeting.
Facilitation Interventions: Fostering Self-Management
In mature Scrum Teams, the Scrum Master may not even attend the Daily Scrum. If the Scrum Master does attend, their stance should be observational and non-directive:
- Breaking Eye Contact with Authority: When developers instinctively address the Scrum Master ("Yesterday I finished ticket 42..."), the Scrum Master should break eye contact, step slightly outside the physical or virtual circle, or redirect attention to the Sprint board. This physically teaches Developers to address each other.
- Coaching on Goal Alignment: When updates drift into trivial operational trivia, the Scrum Master asks powerful coaching questions: "How does what we are discussing right now impact our ability to achieve the Sprint Goal?" or "Are we confident we will meet our Sprint Goal given our current trajectory?"
- Protecting the Boundary: If an external manager attends and begins interrogating developers about task progress or assigning work, the Scrum Master immediately steps in to uphold Scrum boundaries, reminding the manager that the Daily Scrum is an internal developer replanning session and arranging a separate conversation outside the event.
| Daily Scrum Anti-Pattern | Root Cause Dysfunction | Advanced Scrum Master Intervention |
|---|---|---|
| The Status Report to the SM/PO | Lack of self-management; traditional hierarchical conditioning | SM physically steps back; redirects questions back to the team; stops facilitating daily turn-taking. |
| The Technical Rabbit Hole | Conflating inspection with problem solving; lack of facilitation discipline | Coach team on the 16th-minute rule; establish a "parking lot" for post-scrum technical breakouts. |
| Individual Work Silos | Absence of a meaningful Sprint Goal; measuring individuals by task output | Coach PO on formulating cohesive Sprint Goals; introduce right-to-left board walking to encourage swarming. |
| The 45-Minute Marathon | Treating the Daily Scrum as a general catch-up meeting | Enforce the strict 15-minute timebox; remind the team that collaboration happens throughout the day, not just in meetings. |
| Hidden Impediments | Low psychological safety; fear of looking incompetent | Foster openness; coach team that identifying blockers early is a sign of professional competence, not failure. |
The Sprint Review: An Empirical Working Session, Not a Slide Show
The Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog. For a one-month Sprint, the event is timeboxed to a maximum of four hours (and proportionally shorter for shorter Sprints, typically 1 to 2 hours for a two-week Sprint).
The Anatomy of an Authentic Sprint Review
Many organizations misinterpret the Sprint Review as a "Demo"—a staged theatrical presentation where the Scrum Team showcases completed features to a passive audience. In professional Scrum, a demo is merely a subcomponent of a much broader, highly collaborative working session.
The 2017 Scrum Guide listed specific Sprint Review elements; the 2020 Guide simplified this to "the Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed," after which attendees collaborate on what to do next and the Product Backlog may be adjusted. The older elements remain a useful checklist for a rigorous working session:
- Transparency on Done vs. Undone: It is clear which Product Backlog items met the Definition of Done. Items that did not are not presented as part of the Increment; they return to the Product Backlog.
- Developer Reflection: Developers discuss what went well during the Sprint, what problems they encountered, and how those technical or operational problems were solved.
- Hands-On Increment Inspection: Stakeholders actively interact with the working software Increment in a staging or production-like environment, providing immediate, authentic usability and functional feedback.
- Macro Environmental Inspection: The Product Owner reviews market trends, competitor moves, budget status, projected completion dates, and potential customer capabilities.
- Product Backlog Adaptation: The entire group collaborates on what to do next. The Product Backlog is reviewed and updated based on the insights gained during the Sprint, directly shaping the candidate topics for the upcoming Sprint Planning session.
Warning
Never present work in the Sprint Review that does not meet the Definition of Done. Presenting "almost done" or "in-progress" code under the guise of progress destroys transparency, creates false expectations for business sponsors, and invites pressure to release unstable software.
Diagnosing Sprint Review Anti-Patterns
Advanced Scrum Masters must identify and dismantle several prevalent enterprise anti-patterns that undermine the Sprint Review:
1. The "Dog-and-Pony Show" (The PowerPoint Presentation)
In this anti-pattern, Developers spend days preparing polished slide decks, recorded video mockups, or architectural diagrams instead of letting stakeholders inspect working software. This occurs when teams fear exposing bugs or when management expects a corporate executive briefing. The countermeasure is simple: ban slide decks for feature inspection. Mandate that inspection occurs on the live, working Increment.
2. The Gatekeeper Dilemma (Excluding Demanding Stakeholders)
Product Owners or Scrum Masters sometimes deliberately exclude skeptical, vocal, or difficult stakeholders to keep the meeting cordial and avoid uncomfortable conflict. This is a severe anti-pattern. In Scrum, difficult feedback surfaced early is an immense economic gift—it prevents the team from spending months building the wrong capability. The Scrum Master must coach the team to invite all key stakeholders, creating a safe, structured space for constructive candor.
3. The Internal Echo Chamber
Holding the Sprint Review exclusively with internal development personnel—engineers, architects, and internal managers—without actual users, customer proxies, or business sponsors turns the event into an echo chamber. Without real user feedback, the team cannot validate whether the Increment delivers true business value.
4. The Formal Acceptance Sign-Off Trap
Treating the Sprint Review as the formal approval gate where the Product Owner inspects user stories for the very first time to "accept or reject" them is a critical anti-pattern. Product Backlog items should be reviewed and validated continuously throughout the Sprint as soon as they meet the Definition of Done. Deferring acceptance to the Sprint Review creates bottleneck queues, delays feedback, and causes stressful end-of-Sprint surprises.
| Dimension | Passive Feature Demo (Anti-Pattern) | Empirical Working Session (Best Practice) |
|---|---|---|
| Primary Vehicle | Polished PowerPoint slides, recorded videos, or static mockups | Live, usable, interactive Increment meeting the Definition of Done |
| Stakeholder Role | Passive spectators who applaud or listen silently | Active participants who test features, offer critique, and discuss market needs |
| Scope of Discussion | Narrow focus on completed tasks and developer effort | Holistic inspection of value, market conditions, budget, and future direction |
| Outcome | Management approval sign-off or polite applause | Concrete adaptations and reordering of the Product Backlog for next Sprints |
| Handling of Undone Work | Hidden, minimized, or showcased as "90% complete" | Openly acknowledged as not Done; excluded from releasable Increment |
During the Daily Scrum, an engineering director attends and repeatedly interrupts the team members, demanding detailed status updates on individual tickets, criticizing a developer for falling behind on a task, and reassigning an architectural story to another engineer. The meeting frequently drags on for over 35 minutes. How should the Scrum Master intervene?
Allow the engineering director to continue directing the meeting, as senior leadership has organizational accountability for developer performance and delivery schedules across the department.
Ask the Developers to vote on whether they prefer the engineering director to assign their tasks, and abide by the majority decision.
Cancel the Daily Scrum entirely for the remainder of the Sprint to protect the Developers from executive interference and reschedule it once the director has stopped attending.
Coach the director outside the event on the Daily Scrum's purpose, keep the 15-minute timebox, and make clear that observers may not direct the event or assign work to the Developers.
At the Sprint Review, the Product Owner displays a slide presentation showing architecture diagrams and wireframes for a new payment gateway feature. The Developers explain that while the code is written, it has not yet passed automated regression testing or performance verification required by the Definition of Done. A senior marketing executive expresses excitement and asks if the feature can be pushed to production by Friday. How should the Scrum Master respond?
Encourage the team to deploy the unfinished code immediately to capitalize on the marketing executive's commercial enthusiasm while the momentum is there.
Suggest that the marketing executive authorize a temporary waiver of the Definition of Done so the item can be counted as complete for this Sprint and released on Friday.
Clarify that only work meeting the Definition of Done forms a usable Increment, and facilitate an open talk about risks and next steps.
Privately reprimand the Developers after the meeting for mentioning that the code had not completed regression testing in front of business executives.
A Scrum Team's Daily Scrum has devolved into an unproductive ritual where each developer looks directly at the Scrum Master, recites the ticket numbers they worked on yesterday, and states that they have no blockers. Collaboration between team members during the day is minimal, and unfinished work routinely piles up at the end of each Sprint. What should the Scrum Master do to revitalize the Daily Scrum?
Coach the Developers to focus on the Sprint Goal instead of status, try walking the board right to left, and step back so they talk to each other.
Assume the role of meeting chair, calling on each developer in alphabetical order and logging individual hours worked in a project tracking spreadsheet so blockers cannot be overlooked.
Require each developer to write a detailed 500-word daily progress report and email it to the Product Owner prior to the Daily Scrum.
Extend the Daily Scrum timebox to 45 minutes to ensure every developer has sufficient time to explain all technical code commits in depth.
Sections you finish are checked off in the contents.