The 4 Scrum Ceremonies Every Team Should Use
Scrum ceremonies are the key moments where the team coordinates their work, and not just for the current sprint. As a framework for agile software development, Scrum helps teams deliver continuously improving products. Scrum ceremonies ensure that continuity across sprints.
But they can easily be derailed by lack of focus or too many cooks in the kitchen.
So, let’s talk about how to do these meetings the right way.
Side note: you might have heard these ceremonies also referred to meetings or events. They all mean the same thing. Some people recognize more than four Scrum ceremonies—more on that later—but generally, the terms are interchangeable.
First up, how do these ceremonies fit within the larger Scrum framework?
Scrum ceremonies overview
The Scrum software development methodology can be broken down into ceremonies, roles, and artifacts. Each of these terms can be broken down into its separate elements as well.
Backed by Scrum values and theory, these elements constitute the entire Scrum framework. That’s it.
Scrum roles outline the responsibilities and relationships between different members of the Scrum team. The development team is a group of individuals with the technical knowledge to build useful software; the product owner works with the development team and other stakeholders to prioritize product changes; the Scrum master maximizes the value of the team’s work by facilitating processes and improvement.
Scrum artifacts are what the team works on, and no one can make them work on anything else. These are the product backlog, a ranked list of items that represent customer- or stakeholder-driven changes to the product. The sprint backlog draws from the product backlog, containing only items for the current sprint. The product increment is the sum of total of items completed during the sprint and the new functionality they provide.
Scrum ceremonies are structured meetings designed to organize the work of a sprint and to inspect and adapt the product increment in development—from sprint planning, through each daily Scrum, to signing off the increment in sprint review. After completing the sprint, the team conducts the sprint retrospective to identify process improvements for the next sprint.
Check out this post on Scrum artifacts or this one on Scrum team roles for more on that. Let’s take a closer look at each Scrum ceremony and where it falls within the sprint.
The 4 Scrum ceremonies: A timeline
The above timeline is set up for a two-week sprint cadence. From this calendar view, you can get a sense of how sprints build on one another. The four key Scrum ceremonies play a crucial role in organizing the work of the Scrum team—both within the sprint and across multiple sprints.
Each flag you see above marks a ceremony where the team has to make sure it’s following through on its responsibilities. So how do you make that happen?
1. Sprint planning
The first Scrum ceremony is sprint planning. It marks the beginning of the sprint and is timeboxed according to the number of weeks in the sprint. Typically, this is two hours per week of sprint duration. A team with a two-week sprint cadence, for example, would dedicate four hours to sprint planning.
At this ceremony, there are two main objectives:
- The Scrum team decides what items from the product backlog to pull into the current sprint backlog.
- The development team forms a plan for delivering the selected backlog items.
The entire team should be present for sprint planning. Outsiders may attend, but they need to adhere to the norms of the ceremony. Both the development team and product owner have a lot get through—non-team members should be respectful of team goals—and only the development team can decide what items to add to the upcoming sprint.
To determine how many items to add, the Scrum team needs a sense of how long each item will take to complete and the team’s total capacity. This is what’s known as estimating the backlog.
In an ongoing process called backlog refinement, items are continually prioritized, sized, and brought closer to “ready” for the sprint. When it comes time for sprint planning, then, items at the top of the backlog have been reliably estimated by the development team and their priority has been validated by the product owner.
Scrum team capacity is based on two things: the team’s historic performance and current availability.
A lot of people talk about team performance in terms of velocity, the total number of story points the team produces divided by the total number of sprints. So, velocity shows the average number of story points the team can produce during a single sprint, which can help forecast the workload for sprints.
As does the team’s availability. At sprint planning, holidays, travel, illnesses, and other factors have to be accounted for to ensure the team doesn’t spread itself too thin.
Once a team has selected a doable number of backlog items, they need to figure out how to get it done. The second task of sprint planning focuses on converting the backlog items into tasks the development team can accomplish.
The work for the first few days should be fairly well deconstructed by the end of sprint planning, even if the plan toward the end of the sprint is a little less staked out. There are likely to be changes and unforeseen problems, so there’s little use in trying to plan the end of the sprint at the beginning.
That said, team members should leave sprint planning with a strategy for self-organizing the work ahead and a shared definition of what a “done” product increment looks like.
2. Daily Scrum
The second Scrum ceremony, daily Scrum, occurs on every day of the sprint when there isn’t another ceremony. It’s timeboxed at 15 minutes, during which the team comes up with a plan for the next 24 hours.
Tip: Hold daily Scrum at the same time and in the same place each day. The predictability reduces complexity, uncertainty, and helps individual members self-organize according to their own schedule.
Daily Scrum includes the development team, who run the meeting, and the Scrum master. A product owner may attend if helpful. If they don’t, the Scrum master should keep them informed of any major adjustments that might impact the sprint.
The key is to keep this ceremony brief. Daily Scrum isn’t a time for new ideas or one-on-one conversations. During daily Scrum, the team focuses on inspecting progress and identifying any changes to the day’s work. Each member of the development team explains:
- What they have done since the last daily Scrum.
- What they will work on today.
- Any problems preventing them from accomplishing their work.
As I said earlier, at sprint planning, the team agrees on a provisional strategy for accomplishing the work. The team uses daily Scrum to refine that plan each morning. This way, the team is working with a sensible plan throughout the sprint.
3. Sprint review
At the end of the sprint, the Scrum team holds sprint review. The entire team attends, as well as any stakeholders invited by the product owner.
The purpose of sprint review is to inspect the newly created product increment and adapt the product backlog as necessary. By the end of sprint review, the Scrum team should have a revised product backlog and a good sense of what items to move to the upcoming sprint.
The ceremony is timeboxed for one hour per week of sprint duration. For a team with a two-week sprint cadence, sprint review would be two hours long. Like the other ceremonies, it’s up to the Scrum master to keep this event tight and productive.
During sprint review, the product owner and team explain the backlog items they completed. What work is now “done”? What does that “done” increment offer users? With the Scrum team and key stakeholders in one place, sprint review is the perfect opportunity to talk about the progress you’re making on the product.
It’s also a great time to reflect on the utility of the product backlog. Is the team slated to work on the most pressing thing next? What changes need to be made to the product backlog as a result of the work completed? What impediments or new opportunities did you discover during the sprint, and how do they impact the road ahead?
In short, you want to leave sprint review positive that the current product backlog is set up to best use the Scrum team’s resources. The team should feel they are working on items that deliver value and the other stakeholders should agree.
4. Sprint retrospective
After sprint review, but before the next sprint, the team holds the final scrum ceremony: the sprint retrospective, also known as the agile retrospective. Just as the sprint review offers a moment for the team to inspect and adapt the product it’s making, the sprint retrospective is a space for the team to reflect on its process.
Retrospectives are usually timeboxed at 30-45 minutes (depending on team size) per week of sprint duration, though some teams opt to keep retrospectives in this timebox regardless of their cadence.
The Scrum master ensures all team members are present. The product owner may be present, but it’s not mandatory. No need for other stakeholders to attend, either. In fact, some teams might feel uncomfortable inspecting their internal processes under outsiders’ eyes.
The purpose of a sprint retrospective is to improve team processes. Every member of the development team should be given space to:
- Talk about the efficacy of the relationships, processes, and tools the team used to complete the work of the sprint.
- Discuss what worked well and what did not.
- Come up with a plan for the next sprint that capitalizes on pros and addresses cons.
A well-run retrospective will help the team bring potential problems to the surface so they don’t persist in future sprints. This Scrum ceremony is the perfect opportunity to get issues out in the open. Are relationship problems causing problems? Have antipatterns started to develop?
The development team runs the retrospective, though the Scrum master facilitates it. Together, they work to identify areas of improvement and agree on changes for the next sprint.
Tip: Here are a few retrospective exercise ideas that will make your next sprint retro one to remember.
