Agile Ceremonies: Your Ultimate Guide To the Four Stages

by Sean Blake, Head of Marketing

22 Dec 2020

Agile ceremonies are the secret sauce of an agile team’s success. These events or meetings are vital for team organization and increased efficiency.

If the agile ceremonies were NASCAR, these ceremonies would be the stages from planning a race to discussing what to do best in the next one. 🏎️

Well, let us walk you through a complete explanation of what agile ceremonies are. You'll learn their importance, the relationship between them, and a few other things.

Shall we start our engines? 🏁

Try Easy Agile User Story Maps, to help facilitate your Agile Ceremonies

What are agile ceremonies?

The utmost purpose of agile ceremonies is to foster and facilitate team communication. They enable the agile team to be effective as they improve the feedback loop. Plus, they're a sort of guideline for agile development, in which product solutions are created through team collaboration. They help the team stick to agile practices and benefit from them.

The name is quite fancy, but agile ceremonies are four events that occur during a Scrum sprint. These are Sprint Planning, Daily Stand-Up, Sprint Review, and Sprint Retrospective. Without them, agile development could survive, but it couldn't live well.

Now, don't take some kind of agile meetings and add them to a waterfall project to call it an agile project. That's not agile at all, and you wouldn't benefit from it. πŸ‘Ž

The ceremonies apply to the Scrum framework. However, other forms of agile development such as Kanban and Lean have similar kinds of practices.

Once you master Scrum, you'll have the means to solve complex problems in a lightweight manner. Nonetheless, you should have a systematic approach to agile ceremonies.

We'll explore the kinds of attendees, timing, duration, goals, and outcomes for each step of a sprint. We'll also give you some free yet powerful advice to improve the quality of agile ceremonies. πŸ’Ž

Sprint Planning

agile ceremonies: group of gremlins watching a flip chart

Before a sprint starts, some preparation work happens.


The Development Team, the Scrum Master, and the Product Owner. All of them make up the Scrum Team.


At the beginning of each sprint.

For how long?

One to two hours per week of iteration β€” or sprint ⏱️ β€” should be enough. So, if you're planning a two-week sprint, your Sprint Planning should last 2-4 hours. And considering that a sprint is usually no longer than one month, this event shouldn't last longer than eight hours.

Agile framework?

Scrum. Although Kanban teams also plan, they do it less formally and per milestone, not iteration.


This ceremony is the Scrum Team's first step for sprint success. The Product Owner takes the product backlog to this event and discusses it with the Development Team.

The Scrum Master facilitates this Scrum meeting. Together, the Scrum Team does effort or story point estimations. πŸ’ͺ Therefore, the product backlog must contain all the details necessary for estimation. And the Product Owner should be able to clarify any doubts regarding the product backlog. πŸ™‹

WATCH: Eliminate your flat backlog


A decision on the work that the Development Team can complete during the sprint β€” the sprint goal. 🎯 It's an increment of complete work and everyone should feel confident about the commitment So, you might guess that a lot of negotiation occurs during this ceremony.

But remember that the product backlog defines priorities that affect the order of work. Then, the Scrum Master transforms that decision into the sprint backlog.


Break user stories into tasks to get things more operational for the Development Team. And if there's time, assign those tasks during this event.

Focus on collaboration rather than competition. 🀝

Don't forget any member's time off, vacation, or holidays, and keep your team's pace in mind. A track record of the time that the team took to implement similar user stories should help.

Focus only on the product backlog and nothing else in terms of work for the sprint.

Plan your sprints with Easy Agile User Story Maps
Free for 30 days
Try Now
  • Visualize what the team will deliver and when by arranging user stories into sprint swimlanes
  • Drag and drop user stories to prioritize by customer value and business value
  • Drag items directly from the backlog onto the user story map

Daily Stand-Up

After planning the iteration, the work is executed.


The Development Team and the Scrum Master. The attendance of the Product Owner is optional, and some agile teams dismiss the presence of the Scrum Master.


Once a day, usually in the morning. πŸŒ…

For how long?

This is a quick meeting, so 15 minutes should do the trick. That's why you absolutely must have this ceremony standing up.

Agile framework?

Scrum and Kanban.


All members of the Development Team should inform everyone else about how work is going. Due to time restrictions, this event shouldn't be that detailed.

If the team is up for it, this meeting can be quite informal and fun. But the purpose and the outcome of this ceremony must remain intact.

The Development Team members should update each other on what they did the day before and are doing that day. Important: The members must be honest about any blockages they have and ask the team for help.


The Scrum Master should clear all the blockages that either slow down or prevent the Development Team from delivering. 🚧 As a result of the Scrum Master's action, the development process might need to change.

Another important outcome of this event is seeing ways to help each other.


Use a clock alarm to prevent this meeting from exceeding the 15-minute limit. ⏳

Try to hold this ceremony at the same time every day. Set up a routine and ensure that you're discussing no more than a day’s worth of work.

If the team is distributed, use video conferencing, not voice-only calls. πŸ“Ή

Long discussions should happen after this event.

The main goal of a Daily Stand-Up is to encourage progress, which means that everyone should feel accountable.

Sprint Review

Man saying " looks a mess."

Once the sprint’s work is done, it’s time to showcase it and gather feedback.


The Development Team, the Scrum Master, and the Product Owner. Optionally, management, customers, and other external stakeholders go to these meetings.

Even developers from other projects can go. And staff from marketing, sales, and customer support departments might attend as well. A variety of attendees offer early feedback from different viewpoints is precious to build great products.


At the end of the sprint.

For how long?

One hour per week of the sprint. This means that in the case of a one-week sprint, the Sprint Review should last one hour.

Agile framework?

Scrum and Kanban. Kanban teams do these reviews after team milestones, not sprints.


Demonstrate the work that the Development Team did throughout the sprint to collect feedback from everyone involved. It helps build trust among external stakeholders and internal staff.

The Scrum Master takes on the logistics of event preparation. And if necessary, especially when external stakeholders participate in this meeting, rehearse.

The Product Owner should ask questions to external stakeholders and internal staff that don't belong to the agile team. They should also answer any of their questions. πŸ™‹


As a consequence of this ceremony and the feedback, the Product Owner might need to adjust the product backlog. They might also release product functionality if it's already complete.


The Development Team shouldn't showcase incomplete work. But how do they know whether work is complete or incomplete? Well, that depends on Sprint Planning and the original acceptance criteria.

Besides product functionality, focus on user experience, customer value, and business value.

On a final note, feel free to party a little bit to celebrate the team's accomplishments. πŸ₯³

Sprint Retrospective

As with many things in life, the end is almost as important as the beginning. That’s why it’s important to improve what went wrong throughout the iteration and repeat what went well.


The Development Team, the Scrum Master, and optionally the Product Owner.


At the end of a sprint.

For how long?

Forty-five minutes per sprint week.

Agile framework?

Scrum and Kanban. But Kanban teams do it occasionally.


Discuss what went well throughout the sprint and what went wrong. So, the goal of the Sprint Retrospective is to gather rapid feedback for continuous improvement in terms of process.

Additionally, this meeting is a good time to emphasize good practices that the team adopted and should repeat.

Summing all up, this ceremony works as a tool for risk mitigation in future sprints.


It's not only about understanding the problems that happened throughout the iteration. It's about coming up with solutions and an action plan to prevent those process problems from occurring next sprint.


The team shouldn't feel ashamed or fearful of sharing what they did wrong, even when pointing out others' mistakes. Being honest and coming up with ideas to solve process-related problems is the goal at this event.

Consider that tools and relationships are also part of an agile process's success. πŸ‘¨β€πŸ”§ 🀝

Have this meeting regardless of the existence of problems. Things that the team did well should live in team members' minds for an upcoming sprint.

The Scrum Master should encourage the Development Team to speak up and share not only facts but also their feelings. And that's even more important when the Scrum Master feels something is being left unsaid.

Note: Whereas a Sprint Review focuses on the product, a Sprint Retrospective focuses on the process.

Agile lessons to live by

Agile ceremonies play an important part in agile development. If an agile team doesn't hold them, it's like having a layered cake without one of the layers! And you want the full cake, right? 🍰

Each ceremony relates to one another, and they're organized in a timeline for each sprint. Besides, they all have the product backlog and the sprint goal in common.

At the end of the day, agile ceremonies allow agile teams to deliver products faster 🚴 and with better quality. And that should be true to whichever product and tools those teams use to build the product.

Let's clear something up. It may take a while for an agile team to excel at agile ceremonies. But they're undeniably worth the effort. They structure work and get everyone on the same page with regards to the product, communication, and priorities.

There's no recipe for standardized success at agile ceremonies. Every agile team is different, and products are different as well. And just as agile stands for continuous improvement, you can improve your agile ceremonies as time goes by. πŸ™ŒπŸ™ŒπŸ™Œ

On top of that, we can give you a hand with running your agile ceremonies using our apps for Jira.

Easy Agile User Story Maps
Try Now

Subscribe to our blog