Agile Ceremonies – The De Facto Guide, Tips & Techniques

Agile ceremonies mostly originate from Scrum Events described in the Scrum Guide. Originally called Scrum Ceremonies, they are key meetings designed to increase collaboration, transparency and adaptation.

Scrum today consists of 5 core events, each with accompanying artifacts. These events are:

1. The Sprint
2. Sprint Planning
3. Daily Scrum (sometimes referred to as the daily Stand-up)
4. Sprint Review
5. Retrospective

Along with Backlog Refinement, which is mentioned in the Scrum Guide but not defined as a formal event, these 6 events are the most widely adopted Agile ceremonies.

The 15th annual state of Agile report found that 66% of Agile teams were practicing Scrum. With a further 15% performing a form of hybrid Scrum.

With such wide adoption, the effectiveness of these ceremonies has been proven far beyond the confines of the Scrum framework. Now viewed as common Agile ceremonies, many of these ceremonies are established practice for Agile teams, regardless of what framework they adhere to.

In this article we’re going to explore all of these ceremonies, what they are, their purpose and tips to help you implement them.

Daily Scrum/Stand-up

What is the Daily Scrum/Stand-up? The Daily Scrum, sometimes referred to as the daily Stand-up, is a Scrum Event where the team meets daily to coordinate and plan their activities for the next 24 hours.

Like all Scrum Events it is timeboxed, typically lasting 15 minutes and is best when held at the same time and place each day.

The Daily Scrum gets its nickname, “daily Stand-up” from the way the event is typically held. It is commonly a meeting held standing. Team members stand together, often around their team Kanban board and discuss what they did yesterday, what they plan to do today and whether they have encountered any blockers.

What is the purpose of the Daily Scrum/Stand-up?

The core purpose of the Daily Scrum is to inspect the progress towards the Sprint Goal. However for teams that aren’t working in Scrum or using Sprints, the daily Stand-up is still a valuable event where the team inspect and adapt their progress together. This could be the progress towards a feature, release or an outcome.

Holding Daily Scrums increases transparency of the team’s progress as it is discussed daily. Further, it also increases accountability as team members hold each other accountable and most importantly Daily Scrums increase adaptability, providing the team with the opportunity to review and adapt daily.

Who is responsible/facilitates the Daily Scrum/Stand-up?

There is no set facilitator of the Daily Scrum. Effective Daily Scrums promote collaboration and self-organization.

However, it is common for the Daily Scrum to be facilitated by either the Scrum Master or similar role if the team is fortunate to have one.

Who attends the Daily Scrum/Stand-up?

Since the daily Scrum is designed for the team to collaborate and coordinate work, it is attended by the whole team. Stakeholders and other interested parties may attend the Daily Scrum but as observers not participants.

Tips for running an effective Daily Scrum/Stand-up?

It’s important to remember that the Daily Scrum is not a replacement for continuous communication. Team members will still need to communicate throughout the day. The Daily Scrum is designed to identify and plan for these moments, not replace them.

See our guide to the Daily Scrum for a more in-depth look, plus loads of tips.

The Sprint

What is the Sprint?

The Sprint is the heartbeat that Agile teams work from. It’s a time-boxed iteration, typically lasting 2 to 4 weeks.

Sprints are fixed and do not change in duration. There are also no gaps between them; a new Sprint starts immediately after a previous Sprint.

Sprints help teams break their work down into smaller chunks. By working in 2 to 4 week iterations, work needs to be small enough to be accomplished within the Sprint duration. This helps facilitate iterative development and continual value realization.

What is the purpose of the Sprint?

Sprints form a cadence for the team to regularly reflect and adapt. For example, if a team works in 2-week Sprints, this means they have the opportunity to reflect and adapt their plans every 2 weeks.

In addition, Sprints help teams to:

• Break work down into small tasks
• Derisk development by having product increments that are tested and potentially shippable
• Provide continual value to their users through regular product increments

Tips for running effective Sprints

Effective Sprints have a Sprint Goal. The work within the Sprint can change, however it shouldn’t compromise the Sprint Goal.

Sprints are best kept short. The most common Sprint length is 2 weeks and they should conclude with a tested and working increment to the product.

It is important to ensure that your Sprints aren’t too short or you’ll struggle to make meaningful progress.

Conversely if a Sprint is too long it will reduce the level of feedback to the team, which increases risk and lowers your agility. Long Sprints also often run the risk of increasing the complexity of the Sprint, whilst lowering the transparency — going weeks before seeing any progress.

Sprint Planning

What is Sprint Planning?

Sprint Planning is the first event of a Sprint. It is where the team comes together to set a Sprint Goal and plan the work required for the Sprint.

Sprint Planning sets out to answer three key questions:

• Why is this Sprint valuable?
• What can be done this Sprint?
• How will the chosen work get done?

The team will set a Sprint Goal to answer the first question. The second question is resolved through pulling items from the backlog into the Sprint.

The final question is answered by proceeding to break those backlog items down into tasks. These artifacts make up what is known as the Sprint backlog.

Sprint Planning should be timeboxed, lasting a maximum of 4 hours for a 2-week Sprint.

What is the purpose of Sprint Planning?

The main goal of Sprint Planning is for the team to decide on what should be done in the Sprint, why it’s valuable to our customers and business and how it will be achieved.

During Sprint Planning, the Product Owner ensures the team is clear on the product and Sprint Goals and why the Sprint is of value. The team then works collaboratively to define, clarify and refine the work needed to achieve that goal. The key is to create alignment and transparency on what can be done in the Sprint, and why.

When done properly, Sprint Planning helps the team manage capacity. The team should look at their capacity and what is required, determining what is realistically achievable vs not.

Who is responsible/facilitates Sprint Planning?

Sprint Planning may be facilitated by the Scrum Master and is typically broken down into two key sections:

1. Why
2. What & How

The why, which is defining “Why is this Sprint valuable?” is often led by the Product Owner. Whereas the what and how are typically led by the development team with the help of the Scrum Master.

Who attends Sprint Planning?

The entire team should attend Sprint Planning. The Product Owner may be excused from the latter part of Sprint Planning as the team gets into the details on how the work will be done. However it is common for the entire team, including the Product Owner to attend in its entirety.

How to run Sprint Planning?

Sprint Planning can be viewed as three parts.

1. Part One: Why is this Sprint valuable?
2. Part Two: What can be done this Sprint?
3. Part Three: How will the chosen work get done?

This first part is typically led by the Product Owner and should start with the Product Owner presenting their thoughts on the potential Sprint Goal and how it aligns to a higher product goal.

The team then works with the Product Owner to challenge, collaborate and refine the Sprint Goal into something that they believe is both valuable and achievable in the Sprint.

It is important that this first part is done well as it sets the foundation for the remaining sections of Sprint Planning.

After defining the Sprint Goal and why the Sprint is valuable, the team then seeks to decide on what work needs to be done to achieve that goal.

During this part of Sprint Planning the team works with the Product Owner to select items from the product backlog that align with the Sprint Goal. The team can continually ask questions to clarify and refine the backlog items until they are well understood.

The team is responsible for defining what is achievable within the Sprint. The Product Owner sets the priority and helps to determine the value of each backlog item. But it is up to the team to judge—based on experience and previous team performance—what is achievable in the Sprint.

Sprint Planning is finalized by the team breaking down the chosen backlog items into tasks. This is where the team defines how they plan to deliver the chosen backlog items.

At the end of Sprint Planning the team should produce a Sprint backlog which includes their Sprint Goal, the chosen backlog items for the Sprint and a plan on how they intend to achieve the goal and backlog items.

Tips for running effective Sprint Planning

It’s important to invest the appropriate time into Sprint Planning. Many teams will want to rush through Sprint Planning, however in doing so they often miss things which can later lead to unforeseen dependencies or issues. This may jeopardize the feasibility of the Sprint.

For Product Owners, it’s important to have a clear product goal that spans multiple Sprints before you begin to define a Sprint Goal. Ideally your Sprint Goal should be working towards a higher goal.

Finally, when determining what is achievable in the Sprint, a good habit to have is to consider leave and upcoming public holidays. Don’t fret if you don’t get it right the first few times. The longer teams work together the better they get at estimating the workload and the more historical data they will have for what is actually achievable in the Sprint.

Backlog Refinement

What is Backlog Refinement?

Backlog refinement is the act of breaking down backlog items, adding details, removing redundant items and adding new ones. Also referred to as backlog grooming, Backlog Refinement is a ceremony dedicated to managing the backlog.

Although not a formal Scrum event, Backlog Refinement is a common Agile ceremony. Teams often find it valuable to set aside some time to gather and refine the backlog.

What is the purpose of Backlog Refinement?

The purpose of Backlog Refinement is to keep the backlog in a healthy state. During Backlog Refinement the team should always aim to ensure that there are items ready for the next Sprint.

A secondary outcome of Backlog Refinement is building a shared understanding. Backlog refinement is a prime opportunity for team members to ask clarifying questions to ensure that backlog items are well understood.

You can perform Backlog Refinement in many different tools, like Jira, Azure DevOps, Trello, etc. However, we’ve found that lots of Avion customers find the story map is a powerful place to review the backlog.

The story map gives you a clear overview of the backlog, without losing sight of your users' experience and the big picture of the product.

In Avion, you can use our search and filters to show subsets of the story map such as — “stories in release X without a description”.

Want to try Avion for your Backlog Refinement? Start your free trial today.

Who is responsible for/facilitates Backlog Refinement?

As the owner of the product backlog, the Product Owner is responsible for Backlog Refinement. The Scrum Master may help the Product Owner facilitate the ceremony but they are not responsible for ensuring it happens.

Who attends Backlog Refinement?

Typically at a minimum, a subset of the team should attend Backlog Refinement. However it is not uncommon for the entire team to attend as well as key stakeholders or subject matter experts that may give input into the backlog.

Tips for running an effective Backlog Refinement?

Although the agenda and format of Backlog Refinement will largely be based on the backlog and what items are the priority, a good Backlog Refinement ceremony should start with the Product Owner giving the attendees context on their product goal and the current priorities in the backlog. They would then present the highest priority backlog item that needs refining and will walk the attendees through them. The attendees will ask questions and add details, create new stories and modify existing ones as the discussion progresses.

It’s important there is diversity in the attendees at Backlog Refinement. For example, a designer will likely ask different questions than an engineer and QAs are excellent at picking up edge cases. Without that diversity, important details could be missed.

Finally it is important that Backlog Refinement doesn’t become the only time that the backlog is looked at and managed. You can continually refine outside of the ceremony, whenever necessary.

Sprint Review

What is a Sprint Review?

The Sprint Review is one of two ceremonies that finalize the Sprint. During the Sprint Review, the team present what they have produced in the Sprint, typically to their key stakeholders and in some cases, even customers.

Also commonly referred to as the Sprint demo, showcase, etc. This ceremony is designed to create transparency and elicit feedback on the work that the team has done.

What is the purpose of the Sprint Review?

It’s important that the Sprint Review doesn’t become a forum to “dress up” and sell outcomes the team has produced. The primary purpose of the Sprint Review is to provide an opportunity for feedback and adapt their roadmap accordingly.

Who is responsible/facilitates the Sprint Review?

The product team is responsible for the Sprint Review. However it is common for the Scrum Master and/or Product Owner to chair the ceremony.

Who attends the Sprint Review?

The Sprint Review is designed for the team to gather feedback. As such, the team typically invites whoever they wish to seek feedback from. For example, it’s common for teams to invite key stakeholders, dependent teams and in some cases even end users.

It is also common for the Sprint Review to be an open invite to anyone in the organization who is interested. This helps to evangelize and provide transparency of the work the team has done as well as show the value they provide to the organization and customers.

How to run a Sprint Review?

Like all Agile ceremonies, the Sprint Review should happen at the same time and place at the end of each Sprint. It should be timeboxed to a maximum of 2 hours for a 2-week Sprint.

A typical agenda for a Sprint Review may look something like this:

• Welcome 5 mins
• Overview of the Sprint 5 mins
• Demo what was done in the Sprint (incl Q&A) 30 mins
• What’s next? 5 mins
• Close 5 mins

However the exact agenda and details will be dependent on the Sprint outcomes and attendees.

Tips for running an effective Sprint Review?

As mentioned, it’s pertinent that the Sprint Review doesn’t become a stakeholder update or a “show and sell” meeting. It’s therefore best practice to keep it lightweight.

Teams should avoid spending several hours preparing for the ceremony. Any preparation should be kept to a minimum, remembering that the primary purpose of the Sprint Review is to elicit feedback.

A format that I like to use for running Sprint Reviews is using what I like to call the past-present-future format.

• Past: What is the current state of our product? What are the things we have shipped previously and how are they performing?
• Present: What was done in the current Sprint?
• Future: What is next on our roadmap?

What I like about framing the Sprint Review into these three buckets is that it provides a holistic view of how the team and product is doing.

An example of how you might use this format for your Sprint Reviews:

• Welcome 5 mins
• Past 10 mins
  • Present data, findings from research and discuss how previous features/experiments have performed.
• Present 30 mins
  • Demo and Q&A on what was done in the current Sprint.
• Future 5 mins
  • Present the roadmap and what is next for the team.
• Close 5 mins

Retrospective

What is a Retrospective?

The Retrospective is typically the final ceremony that closes off the Sprint before starting a new one with Sprint Planning. During the Retrospective, the team gathers together to discuss how the Sprint went and whether there are opportunities to improve.

Retrospectives are similar to post-implementation reviews and other improvement ceremonies that organizations might already practice. However rather than waiting until the end of the project to discuss, Retrospectives take a more continual approach. In this case, once per Sprint.

What is the purpose of the Retrospective?

Where the Sprint Review is focused on improving “what” the team produced, the Retrospective is focused on improving “how” the team completed the work.

The Retrospective is arguably the most important ceremony for Agile teams. However it is often the first one to be skipped.

Without regular time for the team to discuss and identify improvement areas they will continue to operate sub-optimally and never reach a state of high performance.

When run effectively, Retrospectives can reduce waste, increase throughput and lead to better outcomes.

Who is responsible/facilitates the Retrospective?

Anyone can facilitate the Retrospective. It is common for teams to rotate or bring in an external facilitator. Having a neutral facilitator can be beneficial to remove biases and help drive actions for improvement, however this is not mandatory.

It is also very common for the Scrum Master to initially take the facilitation of Retrospectives, but by no means does this make the Scrum Master the owner of the Retrospective.

Who attends the Retrospective?

The Retrospective is for the team to continually improve how they work. As a result, it is important that only the members of the team attend.

For effective feedback and issues to be raised, the Retrospective must be a “safe space”. Meaning that team members must feel comfortable to speak their mind and raise issues without fear of reprimand. Keeping the attendees within the team helps to facilitate this safe space.

How to run a Retrospective?

A Retrospective can be as simple as discussing:

• What went well?
• What didn’t go so well? And;
• Identifying action items for improvement.

However a common Retrospective agenda is known as the “5 step Retrospective”:

1. Set the stage: Set the goal; Give people time to arrive and get into the right mindset for the Retrospective.
2. Gather data: Help everyone remember what happened during the Sprint and generate a pool of information from each person’s unique perspective.
3. Generate insight: Why did things happen the way they did? Are there any patterns?
4. Decide what to do: Pick the top issues to work on and create an action plan on how you intend to address them as a team.
5. Close the Retrospective: Clarify action items. How could the team improve the Retrospective?

It’s generally easiest to utilize post-its when performing Retrospectives in person or leveraging online whiteboarding tools like Miro / Mural when virtual. There are also online Retrospectives tools, like RetroTool as well.

Tips for running an effective Retrospective?

Retrospectives should never be personal. They should be about what happened and acknowledge that everyone acted with good intentions and made the best decision they could with the information available at the time. As a reminder of this, it is best practice for the facilitator to begin the Retrospective with the prime directive.

The prime directive states:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. — Norm Kerth

Another tip is to allocate adequate time. Typically teams will attempt to complete the Retrospective in less than an hour and whilst this might be possible for experienced teams, most other teams will only scratch the surface, rather than getting down to root causes. When starting out, I suggest at least an hour and a half for your Retrospective.

Conversely it’s important that Retrospectives don’t become a place for complaining. Therefore timeboxing each of the 5 steps in the Retrospective can be effective in ensuring the retro progresses towards actions for improvement.

Finally, a Retrospective is only effective when actions are taken and implemented. Another tip to help ensure actions are done is to make them visible. The most recent update to the ScrumGuide now advocates for adding your Retrospective actions as backlog items to be brought into the Sprint.

Agile Team Ceremonies Summary

Conclusion

All these ceremonies can often be overwhelming and perceived as a lot of meetings. However, when done correctly Agile ceremonies aim to reduce the total number of meetings required.

If you’re struggling with where to start, start small and find what works for you and your team. Then, iterate from there.

Unless you’re practicing Scrum, I recommend that you start with the daily Stand-up and regular Retrospectives, and go from there. As the need arises, introduce more ceremonies – for example, if you find that you need regular time to discuss and plan the week out, why not try to do Sprints and Sprint Planning.

Finally, here's a shareable infographic of all the above images combined: 6 Common Agile Ceremonies Infographic