Scrum Ceremonies Explained: What They Are and When to Use Them 

If you’ve heard of Scrum, a lightweight framework for product development, you’ve probably heard of the Scrum ceremony. Scrum ceremonies – also known as scrum events – are milestone rituals that guide sprints, the two- to four-week workflow units that make up Scrum projects. 

Like everything in this framework, Agile Scrum events happen under the leadership of Scrum Masters. They usually take the form of meetings, and they exist to keep team members organized and sprints on track. 

What Are the 5 Scrum Ceremonies? 

Each Scrum ceremony has a specific purpose and framework. The five Scrum ceremonies are: 

• Backlog refinement 
• Sprint planning 
• Daily Scrum 
• Sprint review 
• Sprint retrospective 

To facilitate productive meetings, the Scrum Master needs to understand each in detail. 

Backlog Refinement 

Backlog refinement is the only Scrum event that doesn’t happen on a schedule. It’s an ongoing process that ensures the product backlog is relevant, clear and current. 

Goals of backlog refinement: 

Scrum teams use the product backlog to plan sprints and envision the next steps. If the backlog isn’t current and valuable, it can steer the team off track. 

Backlog refinement keeps the sprint moving forward. It involves: 

• Adding new items.  
• Re-ordering current items based on priority. 
• Removing outdated or redundant items. 
• Ensuring each product backlog item (PBI) has user value. 

The Product Owner has the power to make executive decisions about the refinement process. They may work alone or collaborate with a team. 

Relevant terms: 

The product backlog is a prioritized list of items that would add value to the end product. Items may be product requirements, technical features, bug fixes and so on.  

The Product Owner represents the client’s interests and is responsible for maximizing product value. Maintaining and managing the backlog is one of their key tasks. They must articulate the product goal and how each item moves the team toward that goal.  

Tips for success: 

1. Conduct backlog refinement regularly: It may help to schedule refinement time after the team has other Scrum events. 

2. Schedule backlog refinement sessions: Team-based product owners may find that it helps to create meetings exclusively for backlog refinement. A set meeting time keeps this important task from falling through the cracks.  

3. Keep it tight: Unlike other Scrum events, backlog refinement doesn’t have a set time frame. However, you should assess each item’s value quickly and make efficient decisions about it. 

Sprint Planning 

This is the first time-sensitive activity in the Scrum sprint. It happens at the beginning of each new sprint and has a maximum length of two hours per sprint week. A two-week sprint would have a sprint planning ceremony of four hours maximum. 

The entire team, including the Scrum Master, Product Owner and Developers, attend the sprint planning ceremony. They use the event to create the sprint backlog, which encompasses the user stories that the development team (developers and testers in the case of a software product development situation) will commit to for the sprint.  

Relevant terms: 

A sprint is the basic unit of work within a Scrum project. It’s a recurring block of time, always the same length, when the team works on a particular deliverable. It lasts no more than a month, but two-week sprints are more common. 

A Scrum team is a small group that consists of the Scrum Master, Product Owner and Developers. According to the official Scrum Guide, the team usually consists of no more than 10 people. 

A sprint backlog includes the sprint goal, relevant subgoals and product backlog items selected for the sprint.  

Goals of sprint planning: 

The sprint planning event should outline the sprint’s goals, subgoals and component tasks. The Scrum Guide suggests using three questions to lead the discussion. 

1. Why is this sprint valuable?  

The Product Owner answers this question by explaining how this sprint could improve the product’s value and usability. The team applies this information to come up with a value-based sprint goal. 

2. What can be done during this sprint?  

Based on the answers to the first question, the Developers and Product Owner select items from the backlog to include. They often adjust the details of each item based on the sprint goal. 

3. How will the chosen work get done?  

The team then gets specific about action items. They identify and prioritize sprint tasks, developing a timeline for the items in the list. Often, this means turning backlog items into work items that take a day or less to develop and test. 

By the end of the event, everyone on the Scrum team should know:  

• The overall sprint goal and any subgoals. 

• Which backlog items will be a part of the sprint. 
• Who is responsible for which tasks. 

The amount of work assigned must make sense given the sprint’s length. If the sprint backlog is unrealistic for any team member, the group should rework it. 

Daily Scrum 

The Daily Scrum is the sprint’s morning standup meeting. It’s the shortest of the five Scrum events — no more than 15 minutes long, according to the Scrum Guide. Ideally, it happens at the same time every day of the sprint. 

The Daily Scrum is for Developers. It allows them to touch base on their progress and seek support for any challenges. The Scrum Master attends to listen to the Developers and offer guidance if necessary. The Product Owner may attend to answer questions, but their presence is optional. 

How it works: 

During the Daily Scrum, each team member shares what they accomplished the day before and what they plan to do that current day. It’s a chance to share existing or possible challenges and address them before they become problems. 

In most Daily Scrums, developers answer three questions: 

• What have you completed since the last Daily Scrum? 

• What will you complete by the next meeting? 
• What’s getting in the way? 

The answers show the Scrum Master who needs support and where the sprint strategy might need adjustment.  

Goals of the Daily Scrum: 

The Daily Scrum exists to identify hurdles before they become roadblocks. Teams learn to pivot quickly and be proactive, reducing the need for more meetings. 

The Daily Scrum also improves communication within the team. It creates a space to share challenges so that they don’t fall through the cracks. At the same time, it encourages team members to ask for support and keep each other in the loop. 

Tips for success: 

1. Use it as a standup meeting: The Daily Scrum traditionally involves everyone standing in the same room together. The standing feature helps to keep the meeting brief by discouraging lingering.  

2. Involve remote team members in the conversation: If any Developers can’t attend at the same time due to time zone issues, send out the three questions on an internal communication service or through email. Encourage one- or two-sentence replies and follow up as necessary. 

3. Save feedback for later: For the Daily Scrum to work, team members must be willing to put everything on the table, including what’s working and what isn’t. Scrum Masters should remind their teams this isn’t a critique or feedback session.  

4. Follow up as necessary: The team can’t solve every problem during the Daily Scrum. The Scrum Master and other Developers need to use what’s said in the ceremony as a prompt to check in throughout the day and help remove roadblocks. That may mean adjusting the backlog. 

Sprint Review 

The sprint review is the second to last Scrum ceremony. It happens after the team has completed all assigned work and has something to show the Product Owner. 

Relevant terms: 

An increment is a steppingstone toward a product goal. Each increment must have an independent value and be usable. It also needs to work in conjunction with other increments.  

A Definition of Done specifies what the increment looks like when finished. 

How it works: 

The full Scrum team must attend the review. The Product Owner and Scrum Master may also decide to invite other stakeholders. It’s common for managers, customers and developers from other teams to attend. 

There are three steps to a sprint review: 

1. The Developers demonstrate completed increments for the Product Owner and other stakeholders. An increment is a unit of valuable work within Scrum. 

2. Stakeholders offer feedback and ask questions about the completed work.  

3. The team processes feedback and determines whether any adjustments need to happen in the product backlog. 

Covering all three steps should take no more than one hour per week of the sprint. 

Goals of the sprint review: 

Inspect the product as it develops. Non-Scrum teams often wait until a product is finished before gathering feedback. The sprint review allows stakeholders to evaluate the product while it’s in process.  

Check whether the team met its objectives. Stakeholders look at each deliverable and decide whether they are within parameters. The results determine the success of the sprint and set up action items for the next one. 

Evaluate the progress relative to product goals. Ceremony attendees look at what has changed with the project as a whole. Everyone discusses progress toward the broader goal, determining whether objectives were met.  

Tips for success: 

1. Don’t skip feedback and discussion: It can be tempting for teams to focus too heavily on the demo aspect of the sprint review. Remember, feedback and evaluation make the next sprint better and more effective. Make space for this step. 

2. Avoid putting developers on the defensive: The sprint review is a constructive setting geared toward creating the best possible product. If the team falls short of a goal or a bug exists, focus on what needs to happen next to solve the problem.  

3. Focus on business value: Ask questions like, “Does this help the user in the way we expected?” Otherwise, the discussion can turn into a surface-level review of whether the product works. 

4. Create action items: Valuable feedback should become new items in the product backlog. The team can work those items into the next sprint. 

Sprint Retrospective 

The sprint retrospective is the final Scrum event. It’s an internal evaluation process that reflects on how the work happened and what the process could look like going forward. 

The retrospective should involve team members only. The Developers and Scrum Master are essential attendees. The Product Owner may attend if their presence would add value. 

The team answers three questions: 

• What went well in general? 
• What was challenging or didn’t work? 
• How could we improve the process? 

The discussion should take no more than an hour and a half for a two-week sprint or three hours for a month. 

Goals for the sprint retrospective: 

The sprint retrospective benefits the team by: 

• Analyzing problems: Examine challenges that came up and how the team did or did not solve them. 
• Finding false assumptions: If an assumption led your team down the wrong path, learn where it came from and how it affected the process. This also improves communication. 
• Making adjustments: The Scrum Master should lead the team in identifying which potential improvements would have the biggest impact. Those become action items for the next sprint. They may also lead to changes in the product backlog. 

Tips for success: 

1. Encourage collaboration: Acting on every idea is impossible. Pursue those suggestions that multiple team members feel would be valuable. Ask the team to work together toward solutions. 

2. Discuss facts, not feelings: Team members should feel comfortable providing honest feedback and recommending improvements. Discourage fault-assigning language and focus on ideas that impact the product. 

3. Find actionable insights: The most valuable insights create meaningful change. Ask follow-up questions and go deeper until you understand the root cause of each issue. 

Sprint Review vs Retrospective 

The review and retrospective consider the most recent sprint in different ways. Most importantly, the sprint review inspects the product while the spring retrospective inspects the team. 

The review starts from the outside. It involves external stakeholders and the development team, all of whom spend the time evaluating product success.  

The retrospective allows the team to look inward. Without the pressure to present their work, the developers can look critically at how they approach problems. The spotlight is less on the product as a deliverable of value, and more on how the team creates that value. 

Master All 5 Scrum Ceremonies in Agile 

Well-run Scrum ceremonies are essential to a successful sprint. Learn more about how to lead these events and other Agile processes with a Certificate in Agile from Villanova University. Taught 100% online, this three-course program teaches the core components of Agile and the Scrum framework and can help you prepare for Agile and Scrum certification.