Sadly, a Scrum ceremony isn’t an ornate presentation that happens after a particularly effective headlock in the British sport of rugby. More’s the pity.
In all honesty, I think the word ceremony is over-egging slightly, whichever way you cut it.
But, inflated titles aside, these ‘ceremonies’ are important for bringing structure, continuous improvement, and opportunities for learning to Scrum projects.
This article will explain what they are and why 4 is the magic number in this case (sorry, Schoolhouse Rock).
A quick reminder about Scrum
Scrum is a framework within the Agile methodology. Originally used in software development, it has since been adapted for many other types of product development.
88% of organizations are moving towards Agile as a way to deliver their projects, with increased flexibility a key reason for the change.
One of the main characteristics of Agile projects is that the deliverable isn’t fully defined. Work is produced over short periods of time (known as sprints) and refined after each sprint to get closer to the desired outcome.
Collaboration is crucial for successfully developing a product using Agile as the project team needs to work closely with business stakeholders to refine the end deliverable.
Regular meetings, or ceremonies, are an important part of tracking progress and continually improving the outcome to meet business requirements.
Scrum is a simple concept, but can be tricky to implement. There are 3 components to the Scrum framework that act as a structure for delivering the work.
Roles
Like any project, defining roles and responsibilities between members of the project team and the business is important, so everyone is clear on who’s doing what.
In the Scrum framework, there are 3 key roles:
- The product owner represents the business and helps translate customer requirements into work packages for the development team.
- The Scrum master oversees the development process and facilitates improvements to it. They make sure team members have everything they need to get the job done.
- Team members Scrum is all about individuals working autonomously to contribute to the outcome.
For more information on the 7 key roles within the Agile methodology, check out our article.
Artifacts
As what the Scrum team is delivering regularly changes, it’s important to track what’s been done and what needs to happen next.
The product backlog lists all the changes requested by a business and is updated after each iteration.
The sprint backlog contains the changes from the product backlog that are still to be made during the sprint that’s in progress.
Finally, the product increment is a list of all the changes made in the current sprint cycle and the new functionality they provide.
Ceremonies
Ceremonies are used to plan and organize the work that’s happening in the current sprint and also at the end of each sprint to review what went well and what might need to be changed for the next iteration.
The 4 Scrum ceremonies in detail
Firstly, let’s look at how the 4 ceremonies fit together to help organize and manage both single and multiple sprints. The below timeline shows a 4-week period during which 2 x 2-week sprints are held.
1. Sprint planning
As you can see from the above, each 2-week sprint starts with a sprint planning ceremony.
During this meeting, 2 main things are decided.
- What to bring forward from the product backlog to the sprint backlog.
- How those things are going to be delivered.
Deciding what to bring forward can be tricky. It requires matching an estimate of how long tasks on the product backlog are going to take to complete with the capacity of the development team.
monday.com’s customizable sprint planning template makes things easy to manage with columns showing item status, owner, priority, and estimated duration.
Unlike other tools, such as Kanban boards, you can also show dependencies, which is great if you have tasks that affect others.
How long should a sprint planning ceremony be?
The Scrum master is responsible for the logistics around the sprint planning meeting. It’s standard practice to allow 2 hours of planning for every week of the sprint. So, a 2-week sprint would have a 4-hour planning meeting scheduled.
Who attends?
The Scrum master, development team, and product owner should all be in attendance.
What gets done?
During the meeting, the team should work together to form a sprint goal. This is important as it brings clarity to the team and stakeholders about what should be delivered by the end of the upcoming sprint. It also provides something to review against at the end.
This is also an important opportunity for the development team to check in with the product owner. They need to agree on the acceptance criteria for tasks and check any assumptions they’re working on.
To end the meeting, the Scrum master should confirm that there’s consensus on what’s being delivered and that there’s a plan in place. This plan will be relatively high-level as the Scrum framework emphasizes self-management by individuals, giving them the space to complete their work how they want.
2. Daily Scrum
Otherwise known as a daily standup meeting, this is a chance for the team to come together to communicate progress. But, the intention isn’t a status update meeting. The purpose is to identify any obstacles that might stop or slow work being done.
Anything that’s identified falls to the Scrum master to manage — their key purpose is to facilitate work getting done as easily as possible.
How long is a daily Scrum meeting?
These are meant to be short! Standard practice is around 15 minutes. If there are topics you think will take longer, encourage that conversation to happen outside the daily Scrum meeting.
Who attends?
This one’s mainly for the development team and the Scrum master. The product owner is an optional attendee.
What gets done?
The point of the daily standup is for each team member to share 4 things:
- What I did yesterday
- What I’m working on today
- What I plan to do tomorrow
- What’s in my way
Using this structure gives the rest of the team a quick overview on progress and identifies any obstacles that need resolving by the Scrum master.
Ideally, this meeting is conducted face-to-face, but it can be done virtually if teams are distributed.
Running the daily Scrum virtually is a piece of cake with monday.com. Our Work OS integrates with all the usual collaboration tools, which means that’s one less thing you have to worry about.3. Sprint review
The sprint review meeting is a chance for the development team to share the work that’s been completed during the sprint with business stakeholders.
It’s an opportunity to gather feedback from them about the work that’s been done and discuss how that informs what needs to be prioritized on — or added to — the backlog.
How long is a sprint review?
As this is about product demonstrations, it’s sensible to allow a couple of hours for this meeting. Rule of thumb is around 1 hour per week of sprint completed. So, a 2-week sprint would result in a 2-hour meeting.
Who attends?
The development team, product owner, and Scrum master should attend, plus business stakeholders. The product owner and Scrum master should work together to determine suitable business representation in advance.
What gets done?
The development team showcases the work that’s been completed during the sprint. The focus should be less on proving things work and more about explaining the value of each element and how it fits into the project overall.
The development team might reference high-level documents such as the project roadmap or software requirements specification to help stakeholders connect with the overall progress.
monday.com’s project roadmap provides a snapshot of the key deliverables and is ideal for helping stakeholders understand how work completed in the current sprint contributes to the bigger picture.
The product owner should lead a discussion with stakeholders about their thoughts. Actionable feedback is captured and added to the backlog. This discussion helps to refine and prioritize the backlog in preparation for the next round of sprint planning.
It’s also an opportunity for the development team to be praised for work completed to date. This should be about building a trusting and productive relationship between the project and the business.
4. Sprint Retrospective
This is the second meeting that happens at the end of each sprint. The sprint retrospective meeting differs from the sprint review as this one isn’t about the work that’s been completed.
It’s much more about continuous improvement and learning from how things went in the previous sprint. This desire to always try to do things better is a key part of Agile project management.
How long is a sprint retrospective?
There’s no set time for a sprint retrospective. How long they take will depend on how long the team has been working together, their experience, and their maturity. Allowing around 1.5 hours for a 2-week sprint is a good place to start.
Who attends?
This is for the Scrum master and the development team to look at their internal processes. The product owner is an optional attendee, and there shouldn’t be business stakeholders.
What gets done?
This is an opportunity for the entire team to offer an honest review of the sprint. Questions could include:
- What worked well during the last sprint?
- What didn’t work so well during the last sprint?
- What could we change to help us improve?
Once all the feedback has been shared, the team should decide on the actions to be taken for the coming sprint. These should be recorded and assigned an owner to make sure that they’re followed through.
monday.com’s sprint retrospective template helps you capture all this information easily. It also allows you to track progress from sprint to sprint through color-coded labels monitoring what’s been implemented and what the team is still working on.
Like anything new, it can take a couple of iterations for change to occur, but the intention for improvement should be strong.
Scrum ceremonies enable collaboration
In this article, we’ve taken a look at the 4 Scrum ceremonies and why they’re important for your project.
Scrum ceremonies ensure there’s visibility of the work being done and allow collaboration between the project team and business stakeholders. This means work can be progressed iteratively, and there’s a shared responsibility for the output.
We can help you get started. At monday.com, our sprint planning template helps you prioritize work for your next sprint and keeps everyone on the same page.
Try monday dev