The Sprint Review Nobody Attends
Northline Logistics runs two-week sprints. The Sprint Review is booked Friday at 16:00 for 25 minutes; the Product Owner reads ticket titles from the board and asks the team to confirm which are finished. No stakeholder has attended in four months. The Retrospective follows immediately, runs 30 minutes, and is regularly used to re-estimate items that will not fit. The Daily Scrum takes 45 minutes because each developer reports progress to the Scrum Master, who updates the board afterwards. Refinement sessions were dropped when the team got busy. In four of the last five sprints the Sprint Goal was abandoned around day six, and the team now declines to write one, calling it paperwork.
1. Diagnose the systemic cause rather than listing event-format errors. Why are Sprint Goals abandoned on day six?
Read the worked answer
Three feedback loops have been severed, and the day-six abandonment is the predictable symptom.
The product loop. With no stakeholders in the Review, the only inspection of the Increment is internal confirmation that tickets are finished. Nothing learned there can reorder the Product Backlog, so the Product Owner has no evidence to order with and reads the board instead. The planned work is therefore never tested against reality.
The planning loop. Refinement was dropped, so items enter the sprint not understood. Size and risk are discovered mid-sprint, around the point of first real contact with the code. That is day six.
The process loop. The Retrospective is used to re-estimate, so the team never changes its system. Whatever caused the overrun recurs by design.
The Sprint Goal then gets written as a summary of the tickets rather than as one objective with a why. A summary goal is broken by any single slip, so abandoning it costs nothing and signals nothing. The Daily Scrum as status reporting to the SM means the team never replans, so nobody notices the slip until it is a fait accompli. The problem is not the agenda of the events; it is that no event currently produces a decision.
2. Redesign the event cadence for this product. Give the purpose, participants, timebox, and one observable success signal for each event you change.
Read the worked answer
Do not add events. Restore the purpose of the existing ones.
Sprint Review - purpose: inspect the Increment with stakeholders and adapt the Product Backlog. Participants: team, Product Owner, plus a standing invite list of operations, support, and two named client contacts. Timebox: 90 minutes, late morning, mid-week. Success signal: at least one backlog item added, removed, or reordered as a direct result of stakeholder input at every review.
Refinement - purpose: get the top of the backlog understood enough to plan. Participants: Product Owner and Developers. Timebox: 60 minutes weekly, booked as a recurring event. Success signal: the team can size the top items without discovering new work mid-sprint; measure items carried over due to underestimated scope, target near zero.
Sprint Goal - purpose: one objective with a why, agreed at Sprint Planning. Success signal: the goal is either met, or its abandonment is a recorded decision with a stated reason and a backlog consequence, not a quiet slide.
Daily Scrum - purpose: replan the day against the Sprint Goal, run by Developers. Timebox: 15 minutes, walking the board from the goal backwards. Success signal: the plan visibly changes when reality changes, and someone other than the Scrum Master speaks first.
Retrospective - purpose: improve the system. Timebox: 90 minutes, separate from any estimation. Success signal: one experiment per sprint with a named owner, reviewed at the next Retrospective.
3. The team says the Daily Scrum wastes time. How do you coach them without imposing a format?
Read the worked answer
Agree with the observation and separate it from the conclusion. Forty-five minutes of reporting to one person is indeed a waste; that is an argument for a different Daily Scrum, not for none.
Start with a question rather than a fix: what would have to be true for fifteen minutes together to be worth more than fifteen minutes apart? Let the team answer. Most teams name the same things - finding out early that the goal is at risk, and not discovering overlaps after the fact.
Then run an experiment for two sprints, designed by the team. A common one: start from the Sprint Goal, ask what threatens it today, agree who does what about that, and stop. Rotate facilitation so it is not the Scrum Master's meeting.
Coach from the side. Observe two sessions without speaking, then give specific feedback: for example, that eight of the twelve minutes were spent on two items that were not at risk. Do not take the meeting back when it drifts.
Finally, make the cost visible if the team keeps the long format: show what else those thirty minutes buy. Servant leadership here means protecting the team's time and building its capability to run its own inspection, not running the inspection for it.