Within the Scrum methodology, Scrum ceremonies are key to projects running smoothly. These ceremonies give structure to the work of each stakeholder involved.
Scrum ceremonies are held to ensure that the product owner, Scrum master, and development team are on the same page.
There are five types of Scrum ceremonies, and all must take place if you want a successful sprint.
We’ve broken down everything you need to know about these ceremonies to help you make the most of your sprints.
What Are Scrum Ceremonies?
Scrum ceremonies are meetings that occur throughout a sprint.
These play a fundamental role in sprints, which lie at the heart of Scrum. Sprints are iterations of work that need to be completed within a set time. A sprint can be broken down into different ceremonies, artifacts, and roles.
Scrum ceremonies are different phases of a sprint that must be completed for the sprint to be properly executed. They ensure that all stakeholders can work towards the completion of the project in harmony.
Each ceremony has a unique role to play and will occur at a different point in the agile sprint cycle.
Who Participates In Scrum Ceremonies?
The main parties involved in Scrum ceremonies are the product owner, development team, Scrum master, and other stakeholders.
Which of these parties needs to attend each ceremony? Well, that depends on the type of ceremony.
We’ll discuss who participates in each Scrum ceremony when we cover each one in depth.
How Long Should Scrum Ceremonies Be?
The length of a Scrum ceremony depends on various factors, including the particular ceremony and the overall length of your sprint.
While different ceremonies have different lengths, all of them are time-boxed. Note that a time box is the maximum amount of time you can spend on a meeting.
Aim to keep meetings on the shorter side. This makes the meetings more efficient, encourages productivity, and stops the team from going off-topic.
Let’s dive in: what are the 5 Scrum ceremonies? When should each one take place, and who should be present?
What Are The 5 Scrum Ceremonies?
There are four official Scrum ceremonies: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
The Backlog Refinement process, while not an official Scrum ceremony, is an ongoing activity that is performed throughout the sprint. This is often considered to be the unofficial 5th Scrum ceremony. Given its important role, we have included it in our discussion.
You know what the 5 ceremonies are called. Now it’s time to explore the ceremonies in a bit more depth.
1. Sprint Planning
Sprint Planning is the first Scrum ceremony and starts off the sprint. Sprint Planning aims to decide the objective of the sprint and how tasks will be executed. Usually, the whole Scrum team will work together to decide this, as it is a collaborative effort.
These meetings tend to last around one to two hours for a typical 2-week sprint. However, a meeting for a month-long sprint could take up to 8 hours. The duration of the sprint planning ultimately depends on the complexity of your task and product backlog.
When planning your sprint, certain decisions need to be made and certain topics need to be discussed.
You will need to decide how long your sprint will be. This is known as the sprint’s time box.
It is generally advised to keep your sprint’s time box under a month. Straight after one sprint ends, you’ll start another.
It’s better to have a higher amount of shorter sprints than fewer longer ones. This way, you have more control over what you are doing and can make adjustments to your tasks easily.
The typical length of a Scrum is two weeks. This is recommended as a starting point. Make sure to increase or decrease this length if the demands of your sprint require it.
The product owner must describe what the objective of the sprint is to the development team. They should also identify which backlog items will help the team achieve this objective. The development team must indicate whether they feel they can achieve the objective in the time box.
Once the team knows what their objective is, they need to discuss how they will achieve it. The development team should plan out the work that needs to be done. They should then negotiate the best plan with the product owner, bearing the effort required in mind.
In this stage, try not to focus too much on the ‘how’. The focus of sprint planning is to identify what the sprint goal is and whether it can be achieved. It’s okay to make some assumptions and figure out the intricacies of how to achieve your goal later on.
The two essential parties involved in the sprint planning are the product owner and the development team. Both need to be present, or else the planning stage will not serve its purpose.
The product owner has to define the objective of the sprint. The development team needs to understand the objective and indicate whether is it achievable or not.
When planning a sprint, consider what needs to be completed in the sprint. A good place to start is the product backlog. Look at what work has already been done in the increment. This will likely give you some inputs you can use in your sprint.
The main outcome of the sprint planning stage is that the development team understands the objective. They must also have an idea of how they will start working towards achieving the objective. This will be evident in the sprint backlog, or a simple to-do list.
2. Daily Scrum
The daily scrum is a short meeting that happens every day during the sprint. During this meeting, the development team will monitor their progress. They will also decide on any adaptations that need to be made for the achievement of their goal.
The purpose of the daily scrum is to increase the chances of the development team meeting their objective. They will discuss any progress that they have made and suggest any necessary adaptations to the original sprint plan.
The daily scrum is not a status update to the product owner or Scrum master. It is also not a problem-solving session for the development team to delve into complex issues.
This is not the time for in-depth discussions about solutions and adaptations. If these discussions need to take place, the development team should rather meet straight after the daily scrum. In fact, this is a very common occurrence.
Ultimately, daily scrums aim to improve communication and collaboration, eliminating the need for many other meetings. They simply make it easier for everyone to stay on track and meet the sprint objective.
To help the product team stay on track and cover everything during the time-box, members typically limit their discussion to answering three questions:
- What work did I do yesterday that will help us achieve the sprint objective?
- What work do I plan on doing today that will help us achieve the sprint objective?
- Are there any obstacles that are preventing me from completing my current work?
When you focus your daily scrum meeting on these three questions, it makes it easy to stay on track. Your team should be able to cover everything you need to within the required time.
The rule of thumb is to limit your daily scrum to 15 minutes. A 15-minute time box helps keep everyone focused and on track. It prevents the team from going on tangents and forces everyone to focus only on what is necessary.
It is recommended to conduct your daily scrum meeting at the time every day. You should also conduct the meeting in the same place. This regularity and consistency help ensure that everyone can commit to, and attend, the meetings. It decreases the chance of scheduling conflicts.
The members of the development team are the main participants of the daily scrum. They will essentially run the meeting, reporting their progress and discussing adjustments along the way.
The product owner and Scrum master do not have to be present at the meeting. They are not active in the development work and are not necessary.
However, they can still add value to the meeting, and can be present should the development team think it beneficial.
For example, the product owner can help adjust the sprint’s backlog items. The Scrum master can also help ensure that everything is running smoothly and no common pitfalls are occurring.
3. Sprint Reviews
The sprint review is the second last ceremony in the sprint. The purpose of the sprint review is to discuss the outcome of the sprint. It is also to consider any adaptions that should be made for future sprints.
Members of the development team must show the results of their work to the key stakeholders. They will also explain to the stakeholders how the work of that sprint contributes towards the overall product goal.
The stakeholders will review the progress, and consider any changes that occurred during the sprint.
Then, the development team and stakeholders work together to decide what the next step is. Stakeholders should voice opinions about any adjustments that need to be made to the product backlog.
The sprint review should involve collaboration between the development team and the stakeholders. Don’t fall into the trap of treating it like a presentation made by the team to the stakeholders!
If you want your sprint review to meet its purpose, the Scrum master, project owner, key stakeholders, and development team needs to be present. Usually, the product owner will invite all the other parties to attend the meeting.
The sprint review is the second last ceremony in the sprint. It should not be longer than four hours for a one-month sprint.
The rule of thumb is to have one hour for every week of the sprint. For example, a one-week sprint should be time-boxed to one hour.
- Members of the development team should go through each item in the product backlog. They should explain which items have been completed and which ones have not.
- The development team should describe which parts of the sprint went well and which ones did not. They should identify any problems they experienced, and how these were solved. If they could not solve a problem, they should explain why.
- The development team should answer any questions the key stakeholders have about the increment.
- The product owner must explain the current state of the backlog. They might also project potential delivery and target dates based on how much progress has been made.
- Everyone must discuss what the next step is. This makes the sprint review a valuable resource that can be used in the next sprint planning meeting.
- Everyone must consider any environmental changes. For example, market changes may influence what the next step should be.
- Everyone should review the budget and timeline.
4. Sprint Retrospective
The sprint retrospective is a ceremony that focuses on continuous refinement and improvement of the sprint process.
According to the Scrum Guide, the sprint retrospective helps you plan how to improve the effectiveness and quality of subsequent sprints.
In some ways, it is similar to the sprint review. Like the sprint review, it takes place after the sprint. It also focuses on evaluating what happened during the sprint and what improvements can be made for the next sprint.
However, while the sprint review focuses on the product, the sprint retrospective focuses on the processes.
During the sprint retrospective, the Scrum team must have a look at how they conducted the last sprint. They should consider the tools and processes used, and even how individuals worked, interacted, and collaborated.
Anything to do with how the Scrum team performed during the sprint is up for discussion. If a team member did something differently to great success, this should be recognized. If assumptions were made that led members astray, this should also be discussed.
The Scrum master will usually run the meeting, and encourage the team to improve its practices and processes.
The sprint retrospective can essentially be boiled down to three questions:
- What went well during the sprint?
- What did not go well during the sprint and could be improved?
- What improvements will the team commit to for the next sprint?
Note that the team should constantly be trying to improve and refine their processes and practices. The sprint retrospective allows the team to ensure this gets done.
It forces them to set aside some time to focus specifically on improvements to their processes that otherwise might not be made.
Typically, the members of the development team are asked to suggest topics that should be discussed. Often, they are asked to write down their thoughts before the sprint retrospective.
Once they have done so, all their thoughts are grouped into different topics and themes. The development team can then vote on which topics and themes they want to discuss at the retrospective.
This allows an agenda to be set that ensures the most important topics are discussed in sufficient detail.
It’s a good idea to keep the development team members’ comments and votes anonymous. This will make them feel more comfortable sharing honest feedback.
All members of the development team need to be present if you want to make the most of your sprint retrospective. The Scrum master should also be present to run the meeting.
Although not necessary, the product owner may want to sit in. They may be able to add valuable insight into the sprint retrospective. After all, product owners are often very involved with the teams and processes.
The sprint retrospective is the final Scrum ceremony and concludes your sprint.
The general rule is that your retrospective should take between 30 - 45 minutes for each week of your sprint. For example, you should spend approximately one hour for a two-week sprint.
Note that your sprint retrospective should be limited to three hours for a one-month sprint.
5. Backlog Refinement
Product backlog refinement (sometimes called product backlog grooming) refers to the updating and refining of the product backlog.
This is a continuous process. However, Scrum teams will often dedicate meetings to backlog refinement.
Product backlog refinement aims to keep the product backlog organized and up to date. This, in turn, makes it easier to use the backlog during this sprint and in the next one.
Backlog refinement involves different practices.
The product owner and development team must ensure that the backlog includes all the appropriate items. They must add new items to the backlog, and remove any redundant, invaluable, or outdated ones.
The development team and product owner must also ensure that the items are arranged in order of priority. The most important items must be at the top.
Backlog refinement also involves adding more details to the items that are already in the backlog. For example, you could add details about an item’s estimated effort or acceptance criteria.
The top items of your product backlog should all be given user stories if they don’t already have them. User stories explain a product feature from the perspective of the end user.
Backlog refinement is different from the other ceremonies in that it does not take place as a set stage in the Scrum. This is why it is often considered the unofficial fifth Scrum ceremony.
It should ideally be happening continuously throughout your sprint. However, most Scrum teams will hold meetings specifically for backlog refinement during the sprint.
Sometimes, teams can schedule a weekly meeting. Other teams may hold multiple backlog refinement meetings a week.
Generally, the less experience your team has (with the work and with each other), the more meetings you should schedule.
The product owner and development team will typically be present in your backlog refinement meetings. This allows your development team to ask the product owner any questions they may have about the product in the backlog.
However, every member of the development team doesn’t need to be present at the meeting. This is because the purpose of the meeting is not to resolve complex issues but simply to ensure that the backlog is up-to-date and accurate.
Which Scrum Ceremony Is The Most Important
Each ceremony has an important role to play. If you forego any ceremony, there will be serious consequences to your sprint.
Without the daily scrum, you cannot ensure that all your work is aligned. You cannot discuss any obstacles that are slowing down the team.
Without sprint planning, it becomes very difficult to know what you are working towards in the current sprint and how you will achieve it. It becomes almost impossible to have a smooth, successful sprint.
Without the sprint review, you will struggle to analyze your outcome and decide what your next step should be.
Without product backlog refinement, your backlog will be disorganized and inaccurate.
However, if we had to choose one ceremony to be the most important, it would have to be the sprint retrospective! This means that you should pay special attention to this ceremony, not ignore the rest.
If your team is going about the process in the wrong way, they won’t know without feedback. They might be using faulty and inefficient processes that are hindering them from achieving the objective in the time box.
Without the sprint retrospective, you won’t be able to address these issues. They will continue into subsequent sprints, and hold your team back from their full potential!
Never underestimate the importance of the sprint retrospective, and ensure to include it in every sprint.
So, what are the 5 Scrum ceremonies?
The Scrum ceremonies were designed to help teams get the most out of their sprints.
These ceremonies can be quite specific. However, they encourage your team to work like a well-oiled machine, which is sure to pay off in the long run.
All it takes is understanding! Be sure to pay attention to each ceremony that should be implemented and conduct yours accordingly. You’ll reap the benefits in no time!