Facilitating Sprint Events

Now that each accountability owns a clear question, the Sprint events are where those owners actually meet and do the work. Think of the five events as one connected empirical loop, not a calendar of meetings: the Sprint is the container, and inside it Planning sets direction, the Daily Scrum corrects course, the Review inspects the product, and the Retrospective inspects the team. Each is timeboxed, and your job is to facilitate so each delivers its purpose rather than just filling its slot.

The five events form one empirical loop inside the Sprint container:

The container itself is your first facilitation tool. Its whole point is to protect focus long enough to produce something valuable, which means the Sprint Goal is what you guard when pressure arrives mid-Sprint. When a stakeholder drops in new work, you have three honest responses, not one. If it's small and doesn't threaten the goal, the Developers absorb it. If it's large enough to put the goal at risk, you take it to the Product Owner to renegotiate scope, because trading work is a value-and-ordering call. And if it would quietly derail the goal for something that could wait, you protect the Sprint and send it to the backlog. The move you're avoiding is silent absorption, where the team keeps saying yes until the goal is dead but nobody actually decided to kill it.

Planning that drifts is almost always planning that skipped the Why. The fix is to run it as three deliberate passes: Why, What, and How. Start with the Why, where the Product Owner frames the objective and the team shapes it into a single Sprint Goal, one coherent outcome you could say out loud. Then the What, where the Developers pull the backlog items that serve that goal, asking "does this help us hit it?" rather than "how much can we fit?" Finally the How, where the Developers sketch enough of a plan to feel the work is credible without designing every line. Keep each pass inside its timebox so the room doesn't sink into solutioning the first item.

The hardest part is resisting the slide from goal to ticket-list. Watch how a small redirect pulls the room back:

• Jessica: So for this Sprint we've got the export bug, two notification stories, and the settings refactor. That's the list.
• Ryan: That's the what. Before we lock it, what's the one outcome this Sprint is really for?
• Jessica: Honestly? Getting notifications reliable enough that support stops getting tickets about them.
• Ryan: Then that's your Sprint Goal. Does the settings refactor serve it, or is it just nearby?
• Jessica: It's nearby. We could drop it if things get tight.
• Ryan: Good. Now the team knows what to protect and what to trade.

Notice Ryan didn't add work or cut it himself. He surfaced the goal so the team could decide what mattered.

The Daily Scrum belongs to the Developers, and its purpose is re-planning the next day toward the Sprint Goal, not reporting status to you. The fastest way to ruin it is to stand at the front collecting updates, because the moment people answer to you, they stop planning with each other. So step back physically and let them run it. Anchor every Daily on the goal with a prompt like "what's our plan to move the goal forward today, and what's in the way?" When a real problem surfaces, name it and park it: "good one, let's take that straight after with the two people who need to be in it," so the fifteen minutes stays about the plan and the debugging happens with the right people, not the whole team. Status-reporting, live problem-solving, and waiting for your questions are the three drifts to catch.

The Sprint closes with two different inspections, and confusing them flattens both. The Sprint Review inspects the product: it should be a working session where stakeholders react to a real Increment and help the Product Owner adapt the backlog, not a one-way demo where they nod and leave. Make it earn their time by showing the Increment against the Sprint Goal and asking for specific feedback ("does this solve the problem you raised?"), so their input genuinely shapes what comes next. The Sprint Retrospective inspects the team: it's where you turn a hard Sprint into one or two owned improvements. Your job is to create enough safety that people are honest, then steer away from blaming individuals toward the system that produced the result, landing on a small experiment someone owns rather than a wishlist nobody does.

The thread through all five events is the same: each is an inspect-and-adapt moment in service of the Sprint Goal, and your facilitation protects that purpose against the dull meeting it could decay into. A short run of practices puts this to work next, beginning with a quick judgment check on the trickiest call: when a mid-Sprint change should be absorbed, renegotiated, or refused. Try running each scenario by asking first, "does this threaten the Sprint Goal?" before you decide.