Commonly referred to as agile ceremonies, the Official Scrum Guide calls them events. But what are we really talking about? These are meetings, which are one important element of agile software development. “Why don’t we just call them meetings,” you ask? Probably because the “m” word has a negative connotation to it in some organizations. Agile ceremonies don’t solve all of a team’s agility problems, but when done properly within the context of a healthy engineering culture and solid engineering practices, they can support effective communication within the team and organization.

Each agile ceremony has a unique objective tied to it and is organized and facilitated in a way that helps the team achieve that goal. As teams mature in their agility, they may notice that they are able to run their agile meetings more efficiently (and potentially spend less time in meetings altogether).

4 Agile Ceremonies to Know

Let’s take a look at 4 agile ceremonies that support teams in effective agile software development. Some of them come from scrum, but can be applied to lean or kanban agile teams as well.

1. Sprint Planning

Vocabulary tip: The term “sprint” comes from scrum and refers to a timeboxed period of development. Other agile frameworks call the timebox an “iteration” and the meeting “Iteration Planning.” Kanban refers to the meeting as “Replenishment.”

What is it?

A sprint planning meeting is held to decide on the work that the team will commit to for the next sprint. The team can review all work items before they commit to ensure alignment, as well as agree on the priority and sequence of the work.

What’s the objective?

The objective is for the team to commit to new work as a team for the upcoming sprint.

How often?

Scrum teams do Sprint Planning at the beginning of every sprint. Kanban teams may choose to replenish at the beginning of every iteration (if they have iterations), or when their number of tickets ready to be worked on gets low. Some kanban teams set a threshold. For example, when 3 tickets are left in their “ready to be worked on” bucket, the team knows to replenish the work by holding a meeting.

To prevent Monday fog and Friday holiday collisions, many teams choose to start and end their sprints mid-week. Here’s a sample sprint schedule for a scrum team:

How long?

For a 2-week sprint, a typical sprint planning ceremony would be 2-4 hours in length.

Who?

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

How?

During sprint planning, the team addresses the following topics:

1. Why is this sprint valuable? Output: The team decides on a sSprint goal.
2. What can be done this sprint? Output: The team selects items from the product backlog to include in the upcoming sprint.
3. How will the chosen work get done? Output: The team comes up with a plan for delivering the backlog items selected for the upcoming sprint.

2. Daily Standup

Vocabulary Tip: Scrum refers to this ceremony as the “Daily Scrum.”

What is it?

A very short, 15-minute (or less) meeting with the entire team for daily coordination, self-organization, and planning. It focuses on how the team can best complete work items and unblock issues. This is not a status update. It is the most regular ceremony used to inspect and adapt.

Think of a team’s daily standup as the huddle before a team makes a play in football or rugby.

What is the game plan for today? Is everyone clear and ready? What do we need to do to make the most of the day? Ready? Ok! Go team!

What’s the objective?

The objective is for the team to check in with each other, recommit to each other, identify what is needed to move forward, and ask each other for help.

How often?

Daily. This doesn’t have to be in the morning, but the daily standup typically signifies the start of a new working day, so you will speak to the last 24 hours and the next 24 hours.

How long?

15-minutes or less.

Who?

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

How?

There are two approaches to stand-up formats:

1. The People-Centric Stand-up

This is the most popular stand-up format, especially for teams using scrum. You go around the room and ask every development team member to answer these 3 questions:

1. What did I get done yesterday that helped the team meet the sprint goal(s)?
2. What will I get done today to help the team meet the sprint goal(s)?
3. Do I see any impediment/blockers that prevent me or the team from meeting the sprint goal(s)?

2. The Work-Centric Stand-up

This format is more commonly used by kanban teams. Teams will walk through their kanban board from furthest-right column down, then the next column to the left and so on.

For each card, the assignee will speak to:

• Progress made
• Plans for today
• Any blockers/flag potential impediments
• Any help that’s needed from their teammates

At the end, give a chance for other team members that don’t have an item on the board to give updates of what they’re working on. This will differ between teams, but it is a great place to start.

Tip: Take discussion about items not displayed on the board offline, or “park” them for a later discussion if there’s time leftover.

3. Sprint Review

Vocabulary Tip: Outside of scrum, this ceremony is commonly referred to as an “Iteration Review.”

What is it?

A live demonstration (demo) where the team shows increments of work to internal and/or external customers. Here, the team gets early feedback to inform future iterations of their product/feature.

What’s the objective?

The objective is for the team to share what they’ve built and get feedback.

How often?

This is decided by the team, but typically once per sprint, typically every 2 weeks or once per month.

How long?

This ceremony is typically 30-60 minutes in length.

Who?

The Development Team, the Product Owner, the Scrum Master, stakeholders, customers, and anyone who’d have valuable feedback on what’s been built to ensure it’s providing the intended value.

How?

1. The Development team demonstrates what was done during the last iteration or what is new.
2. The team shares what goal/epic/feature the demo relates to.
3. The team can share what went well and what challenges were encountered.
4. Stakeholders share feedback and the team can discuss/share where to go from here and then collaborate on any changes/next steps.

4. Sprint Retrospective

Vocabulary Tip: Outside of scrum, this is simply referred to as a “Retrospective,” and in kanban, this is referred to as a “Kaizen.”

What is it?

A meeting where the team can honestly and openly reflect on the team progress, team process, and team health. It is a safe place for the team to regularly reflect and come up with specific steps to improve blockers and pain points—and also celebrate their successes.

What’s the objective?

The objective is for the team to focus on how they can improve their processes and value delivery as a team.

How often?

Typically at the end of each sprint.

How long?

For a 2-week iteration, typically 60-90 minutes.

Who?

The development team, The product owner, and the Scrum Master

How?

Tip: We have a detailed and open-sourced Retrospective Guide available here!

The meeting has a facilitator run the retro (e.g. a Scrum Master or a rotating team member that’s been trained through retrospective facilitator training) and the whole team participates.

1. Set the stage. The team reflects on the timeline that passed
2. Gather data. What do individuals feel was positive, negative and how can we improve?
3. Generate insights. – We identify trends and decide what to focus the discussion on.
4. Decide what to do. Brainstorm concrete actions the team can take to improve.
5. Close. End on a positive note by sharing our team appreciations and self-assign action items.

Agile Scrum Ceremonies Aren’t Everything

Agile ceremonies facilitate communication within the team and organization, but they aren’t a panacea for a team’s agility (don’t believe the agile BS). Successful agile software development requires organizational buy-in from all levels, engagement from engineering, focus on the customer, and potentially bringing in dedicated Agile Coaches.

Share Your Learnings

Do you have other tips and learnings to share on facilitating effective agile scrum ceremonies? We’d love to hear from you in the PagerDuty Community.