The 5 Scrum Ceremonies: What They Are, Purpose & Tips
Scrum ceremonies are a core part of the practice of implementing Agile, a mindset which values people, functional work products, stakeholder collaboration, and adapting to change.
The Scrum methodology and ceremonies are based on the Agile Manifesto, within which sit multiple methodologies to collaborate and function as a team, all with the agile mindset and manifesto in mind.
If you have worked on a team that has talked about “Scrum events,” “sprints,” “backlog grooming,” and “sprint reviews,” it’s likely you have worked with a team that was attempting to operate using the Scrum methodology. Remember, the agile framework is a mindset, Scrum is a methodology.
What Are Scrum Ceremonies?
Scrum ceremonies (sometimes called Scrum events) are important events or elements of the Scrum methodology which follow the agile mindset and are often used in software development or iterative-type projects.
There are five specifically-defined Scrum ceremonies, which I'll review in depth in the next section of this article.
Scrum ceremonies are not just meetings for the sake of having meetings. Rather, they provide the framework for teams to get work done in a structured manner, help to set expectations, empower the team to collaborate effectively, and ultimately drive results.
If they’re not managed appropriately, they can overwhelm calendars and drown out the value they are intended to provide. That said, Scrum itself, like the Scrum ceremonies, is intentionally lightweight and simple.
Learn more in our video guide:
What are the 5 Scrum Ceremonies?
Ready to unpack the five Scrum ceremonies and events? Let's get into their purpose, attendees, and tips and tricks to make them most effective.
Of special note, every single one of these events is time-boxed, intentional, and in service to the overall Scrum team. In other words, they exist to make delivering outcomes possible.
Note: Conducting these events in isolation won’t automatically make your team agile, nor will it ensure your team is operating in the Scrum methodology. In order to effectively run Scrum, these events must be a part of a larger, well-understood, and articulated process.
They should facilitate conversations within the agile team to get things done. And what kind of project manager doesn’t like to get things done?
The Sprint
A sprint in Scrum is a fixed length of time (usually one month or less) where ideas are turned into value. Sprints occur consecutively until the product is complete (or without end). Often, teams measure their future in sprints.
Sprint Purpose
The purpose of the sprint is to time-box work time and get teams to deliver against commitments. Sprints allow goals that are shorter-term, but solid. During a sprint, nothing should change that would endanger the sprint goal.
Sprint Attendees
Entire Scrum team—product owner, development team, and Scrum master.
Sprint Duration
A sprint is anywhere from 1 to 4 weeks, no longer. This limitation allows teams to get moving and deliver incremental progress without driving people crazy.
When I implement Scrum with a new team, I often start with 1 week sprints as we can generally plan 1 week ahead of time. More advanced teams, especially those delivering software, will often run 2 week sprints for more innovation and testing during the timebox.
Helpful Tips
- Sprints are not the enemy, nor are they a motivator. Do not try to coax people to do things because of the sprint itself. Instead, motivate people towards achieving the sprint goal and delivering a product increment.
- Consider when your sprint is going to start and stop. A sprint should start just after the last sprint stops, literally within hours. The time between sprint stop and start should simply be time for your sprint review, retrospective, and sprint planning; then it all starts again!
Anything Else?
Sprints cannot be made longer or shorter. A sprint can only be canceled if the sprint goal becomes obsolete. Only the product owner can cancel the sprint.
Sprint Planning Meeting
The Sprint planning meeting is the Scrum event designed to make sure the team is prepared to get the right things done for the upcoming sprint.
Sprint Planning Purpose
Sprint Planning allows the product owner and development team to review the prioritized product backlog usually in Scrum software or agile project management software. Through a series of discussions and negotiations, they identify items they are committing to complete by the end of the sprint. The product owner is responsible for this.
Sprint Planning Attendees
The Scrum team—the product owner, development team, and Scrum master.
Sprint Planning Duration
The length of most Scrum events is related to the length of the sprint. In terms of sprint planning, it should last 2 times the length of the sprint (in hours).
Helpful Tips
- Epics and user stories can be broken up into smaller tasks & assigned during sprint planning so that everyone knows what they’re accountable to.
- Encourage the team to sketch out tasks, bugs, and any item that requires it during this scrum meeting. It should be an extremely collaborative event.
- Try to have a measure of the team’s velocity before sprint planning begins, assuming you have been operating in the Scrum methodology for a while.
Anything Else?
Sprint planning allows the scrum team to answer the questions, “What can be delivered in this next sprint? And how will we accomplish that work?” It helps provide predictability and creates a collaborative environment..
Sprint Planning Templates
In the DPM Membership templates library, you’ll find a downloadable agenda, checklist, and email that you can tweak to fit the sprint planning needs of your team. This set you up for a productive and useful sprint planning session.
Daily Scrum (Daily Stand-up Meeting)
The daily Scrum is the team’s chance to celebrate recent accomplishments, define a plan for the day, and identify any blockers in the Scrum project.
Daily Scrum Meeting Purpose
This Scrum event is a frequent and regular opportunity where the team meets to communicate individual progress toward the sprint goal. It’s not a status update, but should illuminate any impediments of the team.
Daily Scrum Meeting Attendees
The Scrum master and the development team. The product owner is optional.
Daily Scrum Meeting Duration
This one’s short! It should last no more than 15 minutes. Easier said than done.
Helpful Tips
- Hold the meeting at the same time each day (typically in the mornings), and aim to make this as routine for the Scrum team as possible.
- The daily stand-up should not be canceled if a leader or Scrum master cannot attend. The meeting is for the team; have the daily scrum.
Anything Else?
Alternatively named the daily stand-up or Scrum meeting, this quick pulse check should set up the team for the day, enabling them to be in sync and build trust with each other. Let the team hold each other accountable for achieving their commitments on a daily basis.
Sprint Review Meeting
The sprint review meeting is the Scrum event where all work completed during the previous sprint can be showcased to the stakeholders.
Sprint Review Purpose
At the conclusion of each sprint, the sprint review provides a platform for the development team to showcase all of the work that has been completed. This allows stakeholders to inspect or adapt the product as it emerges.
Sprint reviews can be conducted in a casual nature or they can be more structured. This can depend on product life cycle and release planning.
Sprint Review Attendees
The Scrum team—product owner, development team, and Scrum master. It may also include a mixture of management or outside stakeholders.
Sprint Review Duration
1 hour per sprint week. A 2 week sprint should have a 2 hour sprint review.
Helpful Tips
- The product owner should be asking questions to the stakeholders, gathering feedback, and also providing answers to any that arise.
- Actionable feedback received during the sprint review should be converted into new product backlog items for later prioritization and discussion.
Anything Else?
Also called a sprint demo, this Scrum event helps to build trust across stakeholders and the Scrum team. It is the most direct way for early and frequent feedback to be collected and added to the sprint backlog.
Sprint Retrospective Meeting
The sprint retrospective is the final Scrum event in the sprint sequence that allows the team to look back on the work that was completed and identify items that could be improved for future sprints based on their experiences.
Sprint Retrospective Purpose
After a sprint review has been conducted, the Scrum team needs time to reflect on the work that was just showcased and discuss ways to improve both the output and the agile workflow. All feedback should be collected and assigned in the same way as other epics or stories so the Scrum team understands who is responsible for what and when the changes will be implemented.
Sprint Retrospective Attendees
The Scrum master and development team. The product owner is optional.
Sprint Retrospective Duration
Typically, sprint retrospectives should last no more than 1.5 hours for a two-week sprint. If your sprints are a month, it should be no longer than 3 hours.
Helpful Tips
- When working with partially remote or fully distributed teams, use active collaboration tools such as Mentimeter or Confluence to get folks to participate without having to unmute and share their voice widely.
- If a suggestion for improvement is brought up, ask other members of the Scrum team if they all agree. If so, identify how that recommendation will be brought to life.
Anything Else?
Be sure to create an environment of psychological safety. This is not a blame game. These meetings often illuminate recommendations to be better and mitigate risk moving forward. As a Scrum master, be sure to coach the team to provide honest feedback and be respectful for the course of the event.
The Scrum Roles
Having mentioned a few Scrum roles, let's review what each one is:
- The product owner: This role represents the client and the business in general for the product on which they’re working. They own the backlog and determine the priority of work items for the development team. They make executive product decisions on a daily basis. They’re translating customer needs into actionable work items for the dev team.
- The Scrum master: Scrum masters are accountable for ensuring the team has what it needs to be successful, including a clear understanding of the Scrum process. They are a coach, counselor, advocate, impediment-remover, facilitator, and mediator all rolled into one.
Scrum masters are accountable for establishing Scrum as defined in the Scrum Guide, but they are not project managers (beware any leader that believes these are the same role!)—they are not responsible for the work product. Also, a Scrum master is not necessarily an individual person or a full time job! Read more about Scrum masters vs project managers here. - The development team: This is a group of cross-functional team members all focused on the delivery of working software or the desired output of the team. It includes any product developers, designers, QA, or other technical roles that must collaborate on the actual development of a product.
Ideally, this group of 5-9 people is fully dedicated to one Scrum team. In reality, and at agencies, it might look a little bit different. The development team should be self-organizing and motivated to provide value, and with proper facilitation by a Scrum master and product owner, they can be.
Each of these roles have unique participation in each of the Scrum events. When facilitated effectively, the Scrum events will empower each person in their role to have a great opportunity for success.
Why Are Scrum Events Important?
Scrum events are the heartbeat of the Scrum methodology. Without the events, Scrum can very quickly become a very hard-to-follow and messy process. Especially important with new teams, I encourage folks to implement Scrum as it is written in the Scrum Guide, run a few sprint iterations and then determine what needs to be adapted to best-fit the team.
Note: You’ve probably noticed we didn’t talk about a sprint board (sometimes called a Kanban board) in this article. That’s because it's not a core element of any of the Scrum events. Sprint boards are excellent tools to use in each event, but are not a required element.
Handy-Dandy Comparison Chart
Pressed for time? Check out this brief chart to compare and contrast each Scrum event.
What Do You Think?
Regardless of which project management software you use or the product on which you’re working, these Scrum events are designed to deliver results.
I’ve found that these meetings provide structure and go well when the team is all bought in with a shared understanding of what each scrum event is for. Again, Scrum is a framework to use to help deliver software in an agile fashion.
