Five Events, Five Symptoms
A two-week Sprint team holds a 45-minute Daily Scrum at which the Scrum Master goes person by person asking for status, then updates the board afterwards. Sprint Planning regularly runs three hours and ends with the Product Owner handing out assignments. The Sprint Review is a 30-minute demo to two colleagues from the same department; the Product Owner declares the Sprint 'accepted' and no Product Backlog item changes as a result. The Retrospective has produced the same action - 'improve communication' - for five consecutive Sprints. Sprint length was set by the PMO at two weeks and has never been revisited, and the team has never once discussed whether two weeks is right for them.
1. For each of the four events described, state what the event exists to enable and what the scenario has replaced it with.
Read the worked answer
Daily Scrum - exists so the Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog, producing an actionable plan for the next day. 15 minutes, maximum. Replaced by: a status meeting owned by the Scrum Master, 45 minutes long, whose output is a board update rather than a plan. Note the tell - the Developers leave with no changed plan.
Sprint Planning - exists to establish why (Sprint Goal), what (selected items) and how (a plan), collaboratively, within a timebox of roughly four hours for a two-week Sprint. Replaced by: a work-allocation meeting. The Product Owner distributing assignments removes the Developers' ownership of the how, so the plan is not theirs to adapt later.
Sprint Review - exists as a working session where the Scrum Team and stakeholders inspect the outcome of the Sprint and adapt the Product Backlog. Replaced by: a sign-off gate to two people from the same department, with no backlog adaptation. A Review that changes nothing has produced no inspection.
Retrospective - exists to inspect how the last Sprint went on individuals, interactions, processes, tools and the Definition of Done, and to identify the most helpful change. Replaced by: a ritual producing an unactionable slogan. 'Improve communication' cannot be inspected next Sprint, so nothing can be adapted.
2. Which of these problems can the Scrum Master address within the team, and which require the organisation? Be specific about why.
Read the worked answer
Within the Scrum Master's sphere (coaching and facilitation):
- The Daily Scrum. The Scrum Master can teach that the Developers own the event and can choose any structure that focuses on the Sprint Goal. Insisting on the format is the Scrum Master's own error here - this is the one where the Scrum Master is the problem, not the victim.
- Sprint Planning collaboration. Facilitation, silent estimation, and stopping the hand-out of assignments are all coachable.
- The Retrospective. The Scrum Master can push for one concrete, inspectable change rather than a slogan, and follow up on it.
- The Sprint Review content: who is invited, whether a real increment is shown, whether the Product Backlog is touched.
Requires the organisation:
- The PMO fixing Sprint length and never revisiting it. Sprint length is a Scrum Team decision; a fixed external mandate is an impediment, and the Scrum Master serves the organisation by naming it.
- Stakeholder absence from the Review is partly organisational - if the department two floors away is the only attendee, either the product has no other stakeholders or they were never invited. The Scrum Master cannot manufacture stakeholder interest, but can diagnose which it is.
Distinguish these clearly: taking an organisational problem into a team Retrospective as if the Developers could fix it produces the fifth consecutive 'improve communication'.
3. A Developer proposes cancelling the Sprint Review because 'nobody useful comes'. How do you respond?
Read the worked answer
Push back, but investigate rather than overrule.
Why not cancel: the Sprint Review is the Scrum Team's only scheduled inspection of the Increment with stakeholders. Cancelling it removes the feedback loop that makes the Product Backlog empirical, and it hides the delivery problem rather than solving it. It is also not the Developer's decision to make.
What to investigate first - 'nobody comes' has at least three possible causes with different fixes:
- The increment is not usable or not interesting - demoing on a failing staging environment gives stakeholders no reason to attend.
- The invitation list is wrong - the right stakeholders were never identified, or the Review is scheduled to suit the team.
- The Review has been a demo-and-sign-off, so attendees have learned it is a waste of 30 minutes. This is the most likely explanation given the Product Owner declares Sprints 'accepted'.
What to do: change the Review into a working session - show the increment against the Product Goal, put the next two or three backlog items on the table, and ask stakeholders what they would do. Then measure attendance.
Finally, note the rule for the team's benefit: the only event with cancellation authority is the Sprint itself, cancelled by the Product Owner when the Sprint Goal becomes obsolete. Even then stakeholders must be informed.