Agile ceremonies: what they are and how to run them

Teams that are just starting to work with Scrum often feel confused about which meetings are required, how often they should be held, and what is supposed to happen or be discussed in each one. A practical way to solve that is through agile ceremonies. They give the sprint a clear structure and make iterations more predictable.

In this article, we explain what agile ceremonies are, which types teams usually use, how each one works, and how to run them well.

What are agile ceremonies?

Agile ceremonies, also called scrum ceremonies or scrum events, are recurring meetings that structure work inside a sprint. Some teams also call them agile rituals, though the purpose is very practical: give the scrum team a repeatable rhythm from one iteration to the next. In most Scrum board template setups, there are four core agile ceremonies: sprint planning, daily standup, sprint review, and sprint retrospective.

Here is the quick overview.

The table gives the outline. The real value comes from understanding what belongs inside each meeting and what should stay outside it.

Sprint planning

Sprint planning is one of the most important agile ceremonies because it sets the direction for the sprint before execution starts. This meeting usually happens on the first day of the sprint, and for a two-week cycle it is commonly time-boxed at two to four hours. If the team rushes through planning, the rest of the sprint usually pays for it.

• When: on the first day of the sprint.
• Who attends: the whole scrum team — the product owner, the scrum master, the developers.
• Purpose: select tasks from the product backlog for the sprint backlog and agree on what the team will complete during the sprint.
• Duration: 2 to 4 hours for a two-week sprint, and proportionally less for shorter sprints.

During the meeting, the product owner explains priorities from the backlog. Teams visualizing this work often use kanban boards to track task status across the sprint.

The team reviews the work, checks capacity, and agrees on what can realistically fit into the sprint. By the end, the team should have one sprint goal written as a single sentence and a sprint backlog that supports that goal.

A common mistake is taking too much work into the sprint because the team wants to sound ambitious. The result is usually familiar: unfinished tasks and shaky priorities. Then the next cycle starts with extra confusion already built in.

Daily standup

The daily standup is one of the core agile ceremonies and also the lightest one. It happens every day at the same time and exists to keep the team aligned while work is in motion. The meeting should stay short, because its job is to sync the team and surface blockers early. In Vaiz, those blockers can be tracked directly on the task through dependencies, so the standup has somewhere concrete to leave them.

• When: every day, at the same time.
• Who attends: the scrum team.
• Purpose: a quick sync on what was completed, what is in progress, and whether there are any blockers.
• Duration: strictly 15 minutes.

The classic standup uses these questions:

• What did I finish yesterday?
• What will I work on today?
• Is anything blocking me?

That structure works because it keeps the conversation practical. Everyone leaves with a clearer picture of progress and of the issues that need follow-up.

The most common failure is turning the standup into a manager update. A better habit is to capture blockers fast, then continue the deeper conversation right after the meeting with the people involved.

Sprint review

Among scrum ceremonies, sprint review is the meeting teams most often confuse with a polished demo. It is better to treat it as a working session at the end of the sprint where completed work is shown and feedback goes back into the backlog. This meeting usually happens on the last day of the sprint or one day earlier.

• When: on the last or second-to-last day of the sprint.
• Who attends: the scrum team, stakeholders when needed, such as clients or other teams — worth tracking in a stakeholder register if that group grows past two or three people.
• Purpose: to demonstrate completed work and gather feedback.
• Duration: 1 to 2 hours.

A good review stays close to the actual increment. The team shows what was completed during the sprint, and stakeholders react to what they see. The product owner then updates the backlog based on that feedback.

One detail matters here: unfinished work still belongs in the conversation. A sprint review should help the team and stakeholders leave with the same understanding of what changed and what needs attention next.

Sprint retrospective

Retrospective is often the most useful part of the cycle because it focuses on how the team works. It happens after the sprint review, at the very end of the sprint, and it gives the team time to look at its process with some honesty.

Only the scrum team joins this one. Stakeholders usually stay out, because the meeting works better when the team can speak openly about friction and patterns.

• When: after the sprint review, at the end of the sprint.
• Who attends: only the scrum team.
• Purpose: to improve the team's process, focusing on how the team works rather than the product.
• Duration: 1 to 1.5 hours.

A simple format similar to a Start, Stop, Continue template uses three questions:

• What went well? — what worked well during the sprint.
• What didn't go well? — what slowed the team down or got in the way.
• What will we improve in the next sprint? — specific action items for the next sprint.

This works because it turns vague frustration into clear next steps. By the end of the meeting, the team should leave with a short list of action items that can actually be checked in the next sprint.

The most common mistake is treating the retrospective as a place to vent and then forgetting what was agreed. A better habit is to begin the next retrospective by reviewing the previous action items first. Keep what was agreed in a lessons learned template, so the next review starts from a record, not from memory.

Backlog refinement

Backlog refinement, also called backlog grooming, is not a formal Scrum event, but most teams run it as a fifth ceremony. Its job is to get upcoming work ready before sprint planning, so planning becomes a selection exercise instead of a long discovery session.

• When: once a week in the middle of the sprint, or as a short slot every few days.
• Who attends: the product owner and the developers who will build the work. The scrum master joins when the session needs facilitation.
• Purpose: clarify, split, and estimate the next backlog items so they meet the team’s definition of ready.
• Duration: about one hour per week. Teams usually keep refinement under 10% of sprint capacity.

A refined item has a clear outcome, acceptance criteria, a rough estimate, and no open questions that block the start. If the team keeps discovering missing details during sprint planning, refinement is either skipped or too shallow. A product backlog template helps keep refined and unrefined items visibly apart.

Agile ceremonies by sprint length

The Scrum Guide sets maximum timeboxes for a one-month sprint. Shorter sprints use proportionally shorter meetings, while the daily standup stays at 15 minutes regardless of sprint length.

These are upper limits, not targets. A well-prepared team often finishes planning and review well before the timebox ends.

Do Kanban teams have ceremonies?

Kanban has no sprints, so it has no sprint planning or sprint review. It uses cadences instead: recurring meetings that keep a continuous flow healthy. Most Kanban teams run three of them.

• Replenishment meeting: the team decides which items move from the backlog into To Do, based on capacity and WIP limits.
• Daily Kanban meeting: a short walk across the board from right to left, focused on blocked and aging items rather than on each person’s update.
• Service delivery review: a regular look at lead time, throughput, and blocked work, similar in spirit to a retrospective.

If your team works in continuous flow, start with a Kanban board template and make each card carry enough context to be discussed in the daily meeting. Our guide to the Kanban card shows which fields help.

Running agile ceremonies with a remote team

Remote and hybrid teams need the same ceremonies, but they lose the hallway context that fills gaps in an office. A few habits keep the meetings useful.

• Share the board, not slides. Run planning, standup, and review from the live sprint board so everyone sees the same state of work.
• Move status updates out of the meeting. Ask people to update their tasks before the standup and use the call for blockers only.
• Pick a time that works across time zones. If no shared hour exists, run an asynchronous standup in task comments and keep a live call for planning and retrospective.
• Write down every outcome. The sprint goal, review feedback, and retrospective action items should live next to the tasks, not in a chat thread.

Common agile ceremony mistakes

• Planning without a refined backlog. The meeting turns into requirements discovery and runs over its timebox.
• Standups that report to a manager. The team stops talking to each other and blockers surface too late.
• Reviews without stakeholders. The team demos to itself and real feedback arrives after the next sprint has already started.
• Retrospectives without follow-through. The same problems return because nobody owns the action items.
• Merging ceremonies to save time. A combined review and retrospective usually cuts the retrospective, which is the meeting that improves the process.

How Vaiz supports agile ceremonies

Good tools should support the rhythm of the sprint without pulling attention away from the work. In Vaiz, teams can start with a scrum board template and keep day-to-day progress visible on the same board. Sprint milestones live in the same workspace, and tasks and notes stay close to each other, which makes planning and review easier to manage over time. For teams weighing their options, it's worth seeing how this holds up in Asana vs Vaiz for Scrum.

That setup is especially useful for agile ceremonies for small teams, where one missed update can throw off the whole sprint. It also supports a few basic team habits: keep planning visible and keep blockers easy to spot.

Agile ceremonies FAQ

How many agile ceremonies are there?

Scrum defines four core ceremonies: sprint planning, daily standup, sprint review, and sprint retrospective. Most teams add backlog refinement as a fifth recurring meeting, even though it is not a formal Scrum event.

Are agile ceremonies the same as Scrum ceremonies?

In practice, yes. "Agile ceremonies" usually refers to the Scrum events, because Scrum is the most common agile framework. Kanban teams use cadences such as replenishment and service delivery reviews instead.

Who runs agile ceremonies?

The scrum master facilitates the ceremonies and protects their timeboxes. The product owner leads the backlog side of planning and refinement, and the developers own the daily standup.

What is the difference between a sprint review and a retrospective?

A sprint review looks at the product: what was built and what stakeholders think of it. A retrospective looks at the process: how the team worked and what it will change in the next sprint.

Can a team skip an agile ceremony?

A team can shorten a ceremony when it has nothing to cover, but skipping one regularly removes the feedback loop it exists for. If a meeting feels useless, fix its format in the next retrospective instead of dropping it.

Conclusion

Agile ceremonies cover four separate jobs: planning, daily sync, review, and retrospective. Each of these sprint ceremonies solves a specific problem, so it helps to keep their purposes separate and avoid turning one meeting into another (review should not replace retrospective, and retrospective should not replace review).

For a new team, sprint planning, standup, and retrospective are enough to start. Sprint review can be added once the team has a steadier rhythm.

Ceremonies give the sprint its rhythm. For everything else — how work moves day to day — see agile workflows.