Facilitating the Scrum events

What facilitating an event actually means

Of the several ways the Scrum Guide says a Scrum Master serves the Scrum Team, exactly one concerns the events, and it is worth reading as the list of conditions it is rather than as a job description: "Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox." Three conditions. The event happens. It is worth the hour it costs. It ends on time. Nothing in that sentence says who speaks first, who holds the pen, or what the room concludes.

The everyday misreading turns each condition into a piece of control. Ensuring an event happens becomes chairing it; ensuring it is productive becomes owning its agenda; keeping it in the timebox becomes cutting people off. Scrum defines no chair and no minute-taker, and a Scrum Master who circulates the decisions of each event to management has not documented anything useful — they have built a reporting channel out of the events, and people say different things in a room whose output goes upstairs. The headline accountability sits above all of this: establishing Scrum as defined in the Guide, and helping everyone inside and outside the team understand its theory and practice. That is why a Sprint Review being used as a sign-off gate is the Scrum Master's problem rather than an unfortunate local custom.

The sharpest version of the distinction is a Scrum Master's own absence. Sprint Planning falls on the Monday he is away, and the Developers ask whether to wait until Wednesday. Nothing in Scrum makes an event conditional on the Scrum Master being in the room, and a new Sprint starts immediately after the previous one concludes, so Wednesday is not a delayed start — it is two Sprint days spent without a Sprint Goal or a plan. Appointing a deputy Scrum Master is a heavier fix for a rule that does not exist; Scrum has three accountabilities and no deputies. Handing the chair to the Product Owner is worse, because whoever chairs, selecting what the Sprint takes on is the Developers' decision. If the honest answer is that the team cannot hold a good event without them, that is the coaching goal, not an argument for postponing Sprints.

Who belongs in each room

Each event has a defined set of people because each has a defined purpose, and the pattern is simple enough to carry: Sprint Planning, the Sprint Review and the Sprint Retrospective are the Scrum Team's events, and the Daily Scrum is the Developers'. The Sprint Review is the only one Scrum puts key stakeholders in, and they are there deliberately — it is the event built for the question an outsider is usually asking.

The Daily Scrum is where the exam does most of its work, because Scrum bends the rule once and bends it precisely. The Guide puts it this way: "If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers." Participation follows the work, not the title. A Product Owner carrying two Sprint Backlog items this Sprint is in the event as a Developer, not visiting as a guest who answers priority questions; a Scrum Master carrying none has no participant's seat in it. Reading the rule as a ban on people is the other half of the trap, and it is how candidates lose the item.

Everything else asking for a slot in the Daily Scrum gets declined, and the reason is not arithmetic. A stakeholder who wants two minutes at the end to hear how his feature is going is asking for something legitimate through the wrong door: two minutes fits inside fifteen, and it still converts the Developers' replanning event into a partial progress report, with a precedent waiting for the next person who asks. Scrum already answers him twice — the Product Owner for progress, the Sprint Review for inspecting the outcome. Having the Scrum Master answer on the Developers' behalf, or having them publish a daily written summary, is the same report in another format, paid for by the people doing the work and routed around the Product Owner either way.

Attendance and authority are separate questions, which is what makes the invited adviser worth knowing. Scrum lets the Scrum Team invite other people to Sprint Planning for advice, so the integration specialist nobody on the team can replace is welcome in the room and no Scrum Master approval step exists to gate him. What his presence does not change is who decides: the Developers select the items, and how the chosen work gets done is at their sole discretion, because no one else tells them how to turn Product Backlog items into Increments. An option that lets the expert set how many items the Sprint can hold is wrong however sensible he sounds, and so is one that sends a mid-Sprint change of technical approach to the Product Owner or the Scrum Master for approval. In the other direction, a director who asks to sit quietly in the Retrospective is asking for the one event that inspects the team itself — how the last Sprint went with regards to individuals, interactions, processes, tools and the Definition of Done — and transparency in Scrum is about artefacts and progress being visible rather than about opening every room to every observer. Sending her the improvement list afterwards costs the team the same candour by post.

Timeboxes are ceilings, and the Scrum Team owns what is under them

Every published figure is a maximum and every one of them is quoted for a one-month Sprint: eight hours for Sprint Planning, four for the Sprint Review, three for the Sprint Retrospective. For shorter Sprints the events are usually shorter, and Scrum publishes no scaled number, so an option stating a two-week maximum is inventing one. The Daily Scrum is the exception that gives the pattern away — fifteen minutes whatever the Sprint length, because it is a daily event rather than a per-Sprint one. A team that books four hours for a fortnightly Sprint Review because "four hours is what Scrum says" has inverted a ceiling into a quota, and the ninety minutes in which the event actually achieved its purpose were the successful part.

Under the ceiling, the decision belongs to the Scrum Team, and this is where two opposite wrong answers show up in the same scenario. A delivery manager outside the team who cuts the Retrospective to forty-five minutes is setting the length of an inspection event he does not own, and the organisation is required to give up exactly that. A Scrum Master who simply overrules him has claimed the same ownership from the other side — the service is ensuring the event happens, is positive and productive and stays within the timebox, not deciding how long it runs. A self-managing team internally decides who does what, when and how, and it ends an event when the event has done what it exists to do.

The interesting case is the clock running out with work unfinished. Sprint Planning reaches its eighth hour with a Sprint Goal agreed, items selected and only half the plan detailed. The event ends and the Sprint starts. The Sprint Backlog is an emergent plan the Developers update throughout the Sprint as more is learned, so the question at the timebox is not "are we finished?" but "can the Developers begin?" Extending by two hours buys detail nobody will believe by day four; delaying a day does not create a free day, because the new Sprint has already started; and dropping the undetailed items confuses undetailed with unselected, damaging the Sprint Goal to protect the plan.

Position and regularity are part of the same discipline. Sprint Planning initiates the Sprint, the Sprint Review is second to last, and the Sprint Retrospective concludes it — so a Retrospective booked for the following Tuesday is not a late Retrospective, it is one held inside the next Sprint, paid for out of that Sprint's capacity and looking back at work now a fortnight old. Scrum defines no grace period after a Sprint ends. The Daily Scrum is held at the same time and place every working day of the Sprint for the same sort of reason: fixing them removes a daily negotiation, and an event that floats teaches a team that attendance is a decision and absence is normal.

The four shapes a healthy event gets bent into

The first is the status report. The Developers stand in a circle, each one tells the Scrum Master what they did yesterday and what is blocking them, and nobody has mentioned the Sprint Goal in a fortnight. Asking them to address the same three questions to each other changes the seating and not the output; the problem is that nobody is inspecting progress toward the Sprint Goal or replanning the day. Scrum fixes how long the Daily Scrum is, how often it runs, who it is for and what it must achieve, and leaves the structure to the Developers precisely so that purpose drives it. The diagnostic is one question: if the Scrum Master left the room, would the event still be worth holding?

A related habit is treating those fifteen minutes as the only moment the plan may change. They are an inspection point, not a permission slip — the Guide says outright that this is not the only moment at which the Developers may adjust their plan, and a Developer who finds at half past ten on day six that the agreed approach cannot work should pull in the people she needs now rather than bank a day of wrong work for tomorrow.

The second is the gate. A governance lead arrives at the Sprint Review with a checklist and three required signatures on the minutes before anything reaches customers. The Guide is blunt: "The Sprint Review should never be considered a gate to releasing value." The event is a working session where the Scrum Team and its stakeholders inspect the outcome, discuss progress toward the Product Goal and collaborate on what to do next, and the Product Backlog may be adjusted there to meet new opportunities. Nor is the Review the delivery point: an Increment may be handed to stakeholders before the Sprint ends, because what makes it releasable is meeting the Definition of Done rather than reaching a particular event. Whether a Done Increment is released is a value decision, and value decisions belong to the Product Owner. Accepting the checklist as a Definition of Done misreads the standard the Developers apply as they work for a panel convened afterwards, and moving the signatures to a separate meeting after the Review keeps the gate while tidying the room. The softer version of the same failure is the rehearsed demonstration: work that is not Done should not be shown as Done, but an event the team practises for is a broadcast, and the tell is a Product Backlog that is unchanged afterwards.

The third is the event quietly dropped. Three days before a launch the Developers ask to skip the Retrospective and hold a big one afterwards, and self-management is the persuasive argument for letting them: a self-managing team decides how it works. It decides how it works inside Scrum, not whether the framework's events happen, and the Guide is direct that failing to operate the events as prescribed loses opportunities to inspect and adapt. But winning that argument and getting a resentful room is still a loss. The move is to hold the event and make the launch pressure its subject, because a team under pressure has more to improve than a comfortable one. Escalating to the Product Owner to compel attendance fails twice over — she has no authority over how the Developers work — and folding the reflection into the next Sprint Planning means one of the two gets the leftovers.

The fourth is the improvement that never becomes work. A Retrospective that finds flaky test data costing a day a Sprint has produced a change, not a list, and Scrum gives that change somewhere concrete to live: the most impactful improvements are addressed as soon as possible and may be added to the Sprint Backlog for the next Sprint. A register the Scrum Master reviews with management quarterly hands a team decision to somebody else's agenda while the team pays the cost six more times, and assigning the fix to the Scrum Master misreads causing the removal of impediments as doing the Developers' technical work for them.

Its cousin is the meeting nobody questioned. A programme manager proposes a weekly coordination meeting for two teams on one product. Scrum does not forbid people meeting — Developers meet through the day — but its events exist to create regularity and cut down the need for meetings the framework does not define, so every proposed new meeting is evidence that something an existing event should handle is not being handled. Two teams on one product already share a Product Goal, a Product Backlog and a Product Owner. Asking what the hour is meant to produce is the first move; booking it and using it to brief the programme manager is how a self-managing team learns to wait for someone else to coordinate it.