A Scrum Master is widely described as the person who runs the Scrum events, and that description puts the accountability in the wrong place. Facilitation is the work of helping a group hold the conversation that produces an outcome the group itself owns, so the facilitator carries the process while the group keeps the content. Scrum.org lists facilitation among the focus areas of its Developing People and Teams competency, checked on 8 October 2026, and the 2020 Scrum Guide uses the word once in the whole document. Most of the craft therefore comes from facilitation writing outside the framework, principally Esther Derby and Diana Larsen's Agile Retrospectives from 2006 and Lyssa Adkins's Coaching Agile Teams from 2010.
The line between facilitating an event and running it
One duty covers all five events. The Scrum Master ensures that each one happens, that it is useful to the people in it and that it finishes inside its timebox. Nothing in that sentence makes the Scrum Master the chair. Sprint Planning, the Sprint Review and the Sprint Retrospective are events of the whole Scrum Team, and the Daily Scrum belongs to the Developers alone, so in each case the content is somebody else's.
Running an event means setting its agenda, deciding what the group concludes and reporting the result onward. A facilitator arrives with a structure, proposes it, lets the group change it and keeps the conversation pointed at the purpose the Guide gives the event. When a Scrum Master announces what the Sprint Goal will be, they have crossed from the second description into the first. Reading out a prepared list of actions at the end of a Retrospective is the same crossing.
What each of the five events needs from a facilitator
Every event in Scrum exists to inspect something and adapt something, which is why each one needs a different kind of help.
- The Sprint needs the fewest interruptions and the most protection, since it is the container the other four sit inside, and its length is the one timebox the team chooses for itself.
- Sprint Planning needs the three topics kept apart, because a team that drifts into design before it has a Sprint Goal cannot tell which decisions still matter.
- The Daily Scrum needs fifteen minutes to stay fifteen minutes, with the longer conversations it uncovers moved somewhere they can finish.
- The Sprint Review needs stakeholders to talk, which usually means stopping the team from presenting for forty minutes first.
- The Sprint Retrospective needs evidence before opinions, so that the team argues about what happened and never about whose fault it was.
The common move across all five is making the purpose visible when a group has lost it. A payments team that spends Sprint Planning estimating a migration off a legacy service without ever naming the Sprint Goal has stopped planning, and a facilitator whose only contribution is the question “what is the one objective here” has earned the hour.
The Daily Scrum as facilitation without ownership
The Daily Scrum is the sharpest case, because the Guide gives it to the Developers outright and describes it as a fifteen minute event for them. A Scrum Master working on Sprint Backlog items attends as a Developer, and otherwise attends only if the Developers want them there.
That leaves a narrow and real job. The Scrum Master teaches the Developers what the event is for, helps them find a shape that works for a team spread across two time zones, and notices when the fifteen minutes has quietly become a round of reports addressed to whoever is most senior. Teaching a team to hold its own Daily Scrum well is the outcome, so a Scrum Master still at the centre of the event in the ninth month has left something undone.
What a Scrum Master does when one event keeps failing
A single bad event is a bad day. The same event failing every Sprint is information, and the useful question is what the failure is a symptom of. A Sprint Review nobody attends usually means the stakeholders have learned that nothing they say changes the Product Backlog. A Retrospective that produces the same three actions every Sprint usually means the team has no authority to act on them, which is an impediment outside the event.
Changing the structure is the cheap move and it only works when the structure was the problem. A new Retrospective activity helps a team that has run out of questions to ask itself, and it does nothing for a team whose actions are overruled a week later by a manager the event never invited.
Practise this
Sit in one event this Sprint with a single sheet of paper. Note each speaker, roughly how long they spoke for and whether the contribution concerned the content or the process. Afterwards mark every line that came from the Scrum Master.
Compare the result against the event's purpose in the Guide. A sheet on which the Scrum Master holds a third of the content is describing somebody running the event, and the repair is usually one change to the structure rather than a resolution to say less.