Scrum ceremonies in order: the 4 agile ceremonies and how to run them

Agile ceremonies are the recurring meetings that structure a scrum team's work — in order: sprint planning, the daily standup, the sprint review, and the sprint retrospective. The same four meetings go by many names — scrum ceremonies, agile meetings, scrum rituals, or (officially, in the Scrum Guide) events, with the sprint itself as the container that holds them. Whatever you call them, each has a distinct purpose, a strict timebox, and well-known ways to go wrong — here's all four in the order they happen, plus backlog refinement, in practical detail.

The 4 scrum ceremonies, in order

For a two-week sprint:

Timeboxes scale with sprint length — a one-month sprint allows up to 8 hours of planning, a 3-hour retro, and so on. They are maximums, not targets; healthy teams usually finish sooner.

The ceremony timeline in a sprint

The order never varies, because each ceremony feeds the next: sprint planning opens the sprint, the daily standup repeats every working day, the sprint review closes the sprint's work, and the retrospective follows the review as the sprint's final act — then the next planning restarts the cycle. Backlog refinement runs mid-sprint, preparing items for the next planning.

The timeline for a two-week sprint:

Review and retro on the same afternoon isn't calendar laziness — it's design. The retro works best while the review's feedback is still fresh, and closing both before the next planning keeps the feedback loop unbroken.

Sprint planning

Sprint planning opens the sprint. The team answers three questions, in order: Why is this sprint valuable? (the sprint goal), What can we deliver? (backlog items pulled into the sprint), and How will we do the work? (breaking items into tasks).

A working agenda for two-week sprints:

1. Product owner presents the proposed sprint goal and top backlog items (15 min)
2. Team clarifies, sizes, and challenges scope (30–45 min)
3. Team commits to a realistic set and drafts the plan (30 min)
4. Confirm the sprint goal in one sentence everyone can repeat (5 min)

Some teams close planning with a 30-second ritual: giving the sprint a name. It sounds trivial, but "the Kraken sprint" is far easier to reference in demos and retros than "sprint 47" — a sprint name generator makes it a zero-effort habit.

Anti-patterns to watch: planning by wishful thinking (last sprint delivered 30 points, this sprint plans 45 — a sprint velocity calculator shows the range your team actually delivers), the PO assigning work instead of the team pulling it, and items entering the sprint that nobody refined — which turns planning into a discovery workshop.

Daily standup (daily scrum)

Fifteen minutes, same time, same place. The classic three questions — what did I do, what will I do, what's blocking me — are less important than the actual purpose: inspect progress toward the sprint goal and adapt the day's plan. Many teams get better results walking the board right-to-left (closest to done first) than going person-by-person.

Two rules keep standups worth attending. First, solve nothing in the standup — flag it, name who needs to talk, and take it offline the moment it needs more than a sentence. Second, it's for the team, not for a manager — the moment standup becomes a status report to authority, people optimize for sounding busy instead of surfacing problems.

If your standup regularly runs 40 minutes, that's not a discipline problem to push through; it's a signal the team is too big, the work is too entangled, or the meeting has quietly become something else.

Sprint review

The review closes the loop with the people the team builds for. The team demos the working increment — not slides, not screenshots of staging — and stakeholders react: what's valuable, what's missing, what should change in the backlog.

Treat it as a working session, not a performance. The most useful reviews spend a third of the time demoing and two-thirds discussing what the feedback means for the roadmap. If the review is a rubber stamp where nobody ever changes the backlog afterward, it has stopped doing its job.

Review ≠ retrospective. The review inspects the product with stakeholders in the room. The retrospective inspects the process, team-only. Merging them kills both: honest process talk doesn't happen in front of stakeholders.

Sprint retrospective

The retro is the team's private meeting for improving how it works — the engine of continuous improvement, and the ceremony teams skip first when calendars fill up (which is exactly backward: it's the meeting that makes all the others cheaper).

The reliable structure is five phases: set the stage, gather data silently, group and vote, decide on two or three owned action items, close by reviewing commitments. The full walkthrough with timings lives in our step-by-step sprint retrospective guide, and proven formats — Start Stop Continue, Rose Bud Thorn, 4Ls, Sailboat — are in the template library.

Budget roughly 45 minutes per week of sprint, so 90 minutes for a two-week sprint, with a hard ceiling of three hours for a monthly one. The retrospective timebox calculator works out the split across the five phases for your sprint length and team size — and the phase that gets squeezed when a retro overruns is always "decide what to do", which is the only phase that changes anything. If you want to know what those four ceremonies actually cost the team in hours, the sprint capacity calculator nets them out explicitly.

One rule above all: review last retro's action items at the start of every retro. Teams that skip this train themselves that retro decisions don't matter, and participation collapses within a quarter.

Backlog refinement (the fifth "ceremony")

Refinement isn't an official Scrum event — it's an ongoing activity — but most teams run it as a recurring meeting, and it earns the slot. The team and product owner review upcoming backlog items: clarify intent, split oversized items, add acceptance criteria, and estimate. A common budget is up to 10% of the team's capacity, in practice one hour per week for a two-week sprint.

Good refinement is what makes sprint planning short. If planning keeps blowing its timebox, the fix is almost always upstream, in refinement that didn't happen.

Are there 4, 5, or 6 scrum ceremonies?

Guides disagree on the count, and every number has a defensible taxonomy behind it:

• 4 ceremonies — the recurring meetings inside a sprint: sprint planning, daily standup, sprint review, sprint retrospective. This is what most people mean by "scrum ceremonies".
• 5 events — the official Scrum Guide count: the four meetings plus the sprint itself, which is the container event the others live inside.
• 6 ceremonies — the five above plus backlog refinement, a framing some guides use because refinement occupies a recurring calendar slot on most real teams, even though it's officially an ongoing activity rather than an event.

There is no version of Scrum with secret extra meetings. If something on your calendar is labeled a ceremony and isn't on this list — a status call, a steering update, a demo rehearsal — it's an ordinary meeting wearing a scrum costume, and fair game to cancel.

Do you need all of them?

If you're doing Scrum, yes — the four events are the framework's inspect-and-adapt loops, and removing one usually removes a feedback loop the team needed. But plenty of effective teams don't do Scrum. Kanban teams often keep just a daily sync, periodic replenishment, and a regular retrospective.

The portable core is this: strip away the labels and every type of agile meeting does one of four jobs — a moment to commit (planning), a moment to coordinate (standup), a moment to get feedback (review), and a moment to improve (retrospective). Whether you call them ceremonies, events, rituals, or just meetings matters much less than whether each one still produces its outcome — and the retrospective is the one that keeps the other three honest.