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 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.

• 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.
• 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 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.

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, keep day-to-day progress visible on a scrum board, and track sprint milestones in the same workspace. Tasks and notes stay close to each other, which makes planning and review easier to manage over time.

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.

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.

For more guides on agile and project management, visit the Vaiz blog.