The Four Scrum Ceremonies: How to Run Each One

Sprint Planning opens each sprint. The Product Owner presents the highest-priority backlog items. The team discusses how to build them, asks clarifying questions, and estimates the work required.

At the end of planning, the team commits to a sprint goal: one sentence that describes what a successful sprint looks like, and a sprint backlog: the specific items they will complete to achieve that goal.

Time limit: no more than two hours per week of sprint length. A two-week sprint gets a four-hour maximum. If planning regularly runs over, the backlog is not sufficiently refined. Add a weekly backlog refinement session between sprints to prevent this.
Sprint Planning opens each sprint. The Product Owner presents the highest-priority backlog items. The team discusses how to build them, asks clarifying questions, and estimates the work required.

Common failure mode: sprint planning ends with a list of tasks but no sprint goal. Without a goal, the team has no shared definition of sprint success and no basis for making tradeoff decisions when new information arrives mid-sprint.

The Daily Scrum is a 15-minute synchronization event for the development team. The traditional format asks each team member three questions: what did I complete yesterday, what will I complete today, and what is blocking me. An increasingly popular alternative is board-first: walk the board from right to left (Done to Backlog) and discuss what needs to move.

The standup is not a status report to the scrum master or manager. Managers present in the room observe but do not direct. If a manager starts asking detailed questions or redirecting priorities during standup, it signals that the team’s self-organization is not being respected.

Common failure mode: the standup becomes a long discussion of solutions rather than a surfacing of blockers. The scrum master’s job is to note the blocker and schedule a follow-up conversation with the relevant people after standup. Solving problems during standup causes it to run long and discourages team members from raising blockers.

The Sprint Review is a working session, not a formal presentation. The team demonstrates completed work to stakeholders using the actual product, not slide decks. Stakeholders provide feedback that the Product Owner incorporates into the backlog. The output is an updated backlog and stakeholder alignment on what comes next.

Time limit: one hour per week of sprint length. A two-week sprint gets a two-hour maximum.

The review should include only work that meets the Definition of Done. Demonstrating incomplete or half-working features erodes stakeholder trust and creates confusion about what the product can actually do. If nothing is done enough to demonstrate, say so directly and explain what happened. That conversation is more valuable than a demo of broken features.

Common failure mode: the sprint review becomes a passive presentation with no real stakeholder engagement. If stakeholders are watching but not contributing feedback, the review is not serving its purpose. Design the session to require input: show something, ask a specific question, and wait for the answer.

The Sprint Retrospective is the team’s opportunity to inspect how it worked during the sprint and commit to at least one meaningful improvement. The classic format asks three questions: what went well, what did not go well, and what will we change. The output is one to three specific, actionable changes that will be implemented in the next sprint, each owned by a named person.

Time limit: 45 minutes to 90 minutes. Longer retrospectives with large change lists rarely produce proportionally better outcomes.

Psychological safety is a prerequisite. If team members do not feel safe raising real problems without professional consequences, the retrospective produces only safe observations. The scrum master’s job includes cultivating the team culture that makes honest retrospectives possible. This takes more than one sprint.

Common failure mode: the retrospective produces a list of observations but no commitments to change. A retrospective that ends with ‘we should communicate better’ is not useful. A retrospective that ends with ‘we will add a five-minute scope review to every standup starting next sprint, owned by the scrum master’ is useful.