Agile Ceremonies: The 4 Scrum Events Explained
Agile ceremonies are the four recurring meetings that give every Scrum sprint its shape, its direction, and its built-in moments to improve. Most teams also run a fifth, ongoing activity called backlog refinement, which keeps the work queue healthy between sprints.
The term "ceremonies" is common in the agile community, but the official Scrum Guide by Ken Schwaber and Jeff Sutherland calls them events. Both words mean the same thing in practice: structured, time-boxed meetings that happen at predictable points inside a sprint.
What are agile ceremonies?
Agile ceremonies are the formal checkpoints built into the Scrum framework to ensure teams plan, coordinate, inspect, and adapt on a regular cadence. Each ceremony has a clear purpose, a fixed maximum duration (its timebox), and a defined set of participants.
Without them, sprints tend to drift. Work gets started without a shared goal. Small blockers go unspoken for days. And at the end of a sprint, teams ship something but never ask whether they could do it better next time.
Key Facts
- The 2020 Scrum Guide defines four official events: Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The sprint itself is also considered a container event.
- Timeboxes are hard maximums, not targets. A two-week sprint's planning meeting is capped at four hours; the Daily Scrum is capped at 15 minutes.
- According to the 17th State of Agile Report (2023), Scrum remains the most widely used agile framework, adopted by over 87% of agile teams surveyed.
One useful framing: think of agile ceremonies as the operating system of a sprint. The work is the application; the ceremonies are the scheduled processes that keep everything running in sync.
The 4 agile ceremonies at a glance
| Ceremony | Purpose | When | Timebox (2-week sprint) | Who attends |
|---|---|---|---|---|
| Sprint Planning | Define the sprint goal and select backlog items | Start of each sprint | Max 4 hours | Scrum Master, Product Owner, Dev Team |
| Daily Scrum (standup) | Sync on progress, surface blockers | Every day of the sprint | Max 15 minutes | Dev Team (SM and PO optional) |
| Sprint Review | Demo completed work, gather stakeholder feedback | End of sprint | Max 2 hours | Scrum Master, PO, Dev Team, stakeholders |
| Sprint Retrospective | Reflect on process and plan one improvement | After review, before next sprint | Max 1.5 hours | Scrum Master, PO, Dev Team |
Timeboxes scale with sprint length. For a one-week sprint, cut each timebox roughly in half.
Sprint planning
Sprint planning opens every sprint. The team, the Product Owner, and the Scrum Master meet to answer two questions: what will we do this sprint, and how will we do it?
The Product Owner walks through the top items in the product backlog. The development team selects the items they believe they can finish within the sprint and creates a sprint goal that ties those items to a business outcome. They also break down selected items into tasks small enough to track daily.
A sprint planning session done well takes under two hours. Done poorly, it becomes a four-hour negotiation that leaves the team exhausted before the sprint begins.
Read the full guide: Sprint Planning: How to Run an Effective Sprint Planning Meeting
Daily standup (daily scrum)
The daily standup is the shortest ceremony in the Scrum calendar: 15 minutes, every working day, same time and place. The purpose is synchronization, not status reporting to a manager.
Each team member shares what they worked on yesterday, what they plan to do today, and whether anything is blocking them. The conversation surfaces blockers early so the team can resolve them the same day rather than discovering them at the sprint review.
The Scrum Master does not run the standup like a moderator running a meeting. The development team owns it. The Scrum Master's job is to remove blockers that surface during the 15 minutes, not to collect individual status updates.
Read the full guide: Daily Standup: How to Run a 15-Minute Sync That Works
Sprint review
The sprint review happens at the end of the sprint. The team demonstrates what they built, and stakeholders see working software (or a working increment) for the first time. This is not a presentation of slides. It is a live look at actual output.
Stakeholders ask questions, give feedback, and help the Product Owner decide what should come next in the backlog. The output of a sprint review is a revised backlog, not a signed-off deliverable.
This ceremony is where the team's work becomes visible to the business. It also prevents the classic trap of building in isolation for months and discovering misalignment only at launch.
Read the full guide: Sprint Review: How to Demo Work and Gather Feedback
You may also want to look at acceptance criteria to understand how teams define what "done" means before the review starts.
Sprint retrospective
The retrospective closes the sprint cycle. After the review, the Scrum team (Product Owner included) meets privately to talk about how they worked together, not what they built.
The classic format asks three questions: what went well, what could have gone better, and what will we change next sprint? The team picks one or two concrete actions to implement in the next sprint, then tracks whether those actions actually helped.
This ceremony is often the first to get cancelled when teams are under pressure. That is a mistake. Continuous improvement compounds. A team that runs honest retrospectives every two weeks improves significantly over a quarter. A team that skips them tends to keep making the same mistakes.
Read the full guide: Sprint Retrospective: A Practical Guide to Running Them Well
Backlog refinement: the fifth, ongoing activity
Backlog refinement (sometimes called backlog grooming) is not listed as an official ceremony in the Scrum Guide, but most Scrum teams treat it as a recurring activity. It typically happens once or twice per sprint, mid-cycle.
During refinement, the Product Owner and development team review upcoming backlog items. They clarify requirements, add acceptance criteria, split large stories into smaller ones, and estimate effort. The goal is to keep the top of the backlog sprint-ready so that planning meetings do not grind to a halt over undefined work.
A well-refined backlog cuts sprint planning time in half.
Read the detailed breakdown: Backlog Refinement: What It Is and How to Run It
How the ceremonies fit together in a sprint
Picture a two-week sprint as a loop. Here is how the ceremonies land inside it:
Day 1, morning: Sprint Planning. The team sets the sprint goal and selects items from the product backlog. The sprint backlog is created.
Days 1 through 9, every morning: Daily Scrum. Fifteen minutes of synchronization. Blockers are raised, resolved, or escalated the same day.
Mid-sprint (around Day 5 to 7): Backlog Refinement. The team looks ahead at the next sprint's backlog items to keep them well-defined.
Day 10, afternoon: Sprint Review. The team demos completed work to stakeholders. Feedback feeds back into the product backlog.
Day 10, late afternoon: Sprint Retrospective. The team reflects on how they worked. One or two improvements are committed to for next sprint.
Day 11, morning: the next Sprint Planning. The loop begins again.
That sequence means every sprint starts with intention (planning), stays aligned daily (standup), ends with transparency to the business (review), and closes with a concrete improvement (retrospective). None of the four ceremonies is optional without accepting the risk that the step it covers goes unmanaged.
Common mistakes with agile ceremonies
Turning standups into status reports. When a manager asks each person to report on their tasks in sequence, the standup becomes a status call. The team stops talking to each other and starts talking to the manager. Blockers go unaddressed because raising them feels like an admission of failure.
Running sprint reviews without real stakeholders. A demo where only the dev team and the Scrum Master are in the room is not a sprint review. It is a team meeting. Stakeholder feedback is the entire point.
Skipping the retrospective when the sprint was rough. Teams skip retros precisely when they need them most. A difficult sprint is the best time to look at root causes rather than keep pushing forward.
Letting planning overrun its timebox. A four-hour cap on a two-week sprint planning is already generous. If the meeting consistently hits the cap, the backlog is probably not refined enough.
Conflating the sprint review with stakeholder approval. The sprint review gathers feedback. It is not a sign-off gate. Treating it as one adds bureaucracy and slows delivery.
Not acting on retrospective action items. Teams that identify improvements but never implement them lose trust in the ceremony. If nothing changes after the retro, teams stop bringing real problems to it.
Frequently asked questions
What are the 4 agile ceremonies?
The four agile ceremonies in Scrum are: Sprint Planning (sets the sprint goal), the Daily Scrum (15-minute daily sync), the Sprint Review (demo to stakeholders at end of sprint), and the Sprint Retrospective (process improvement reflection after the review). The Scrum Guide officially calls them "events," but "ceremonies" is the widely used term in the agile community.
Is backlog refinement a ceremony?
Backlog refinement is not listed as an official event in the Scrum Guide, so technically it is not one of the four ceremonies. But most Scrum teams treat it as a recurring meeting within the sprint. It is often called the "fifth ceremony" informally. Without it, sprint planning tends to stall on poorly defined backlog items.
Why are they called ceremonies?
The word "ceremony" implies ritual and intentionality: a structured activity that the team commits to performing at a regular interval. It signals that these meetings are not ad hoc. They have defined outcomes, timeboxes, and participants. The Scrum Guide moved away from the term "ceremonies" in favor of "events" starting with the 2017 edition, but the older term stuck in everyday use.
How long should each ceremony be?
Timeboxes in the Scrum Guide are defined for a one-month sprint. For a two-week sprint: Sprint Planning up to 4 hours, Daily Scrum 15 minutes, Sprint Review up to 2 hours, Sprint Retrospective up to 1.5 hours. These are maximums. Shorter sprints use proportionally shorter timeboxes. The key principle is that a ceremony should end when its purpose is achieved, not when the clock runs out.
Can ceremonies be held asynchronously?
The Daily Scrum is the one ceremony teams most often adapt for async. Tools like Slack threads or async video updates can work, but they require discipline to ensure blockers get surfaced and addressed quickly. The other three ceremonies (planning, review, retrospective) rely on real-time discussion and decision-making. Async versions of those tend to produce weaker outcomes because the conversation that generates alignment and insight does not happen naturally in writing.
Agile ceremonies are not overhead. They are the mechanism that turns a group of individuals into a self-organizing team that learns and improves sprint over sprint. Get the ceremonies right, and the sprint rhythm becomes self-sustaining.
Senior Operations & Growth Strategist