The 4 Scrum Ceremonies Made Simple: A Quick Guide To Scrum Meetings

Alexa Alfonso
Jul 6, 2018 · 11 min read
Image for post
Image for post

Scrum ceremonies are important elements of the agile software delivery process. They are not just meetings for the sake of having meetings. Rather, these ceremonies 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, however, they can overwhelm calendars and drown out the value they are intended to provide.

These ceremonies fulfill & enable several core/original principles. Often, when teams abandon certain ceremonies it’s because they don’t see the value in them anymore, which indicates they may have also abandoned the principles.

In this article, we will unpack the four scrum ceremonies, delving into their purpose, attendees, and tips & tricks to make them most effective. The four ceremonies are:

  1. Sprint Planning

It is important to note that these ceremonies are specific to the scrum framework, an agile process that teams use around the world to build things that work. Scrum is intentionally lightweight and simple, but it is difficult to master. It is intended to provide a framework for cross-functional teams to solve complex problems.

Simply put: scrum is a way to implement agile.

Conducting these meetings in isolation won’t automatically make your team agile. They have to 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?

Before we get too far, let’s quickly review the three roles in scrum.

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 & strive to prioritize items to be worked on before every sprint. They make executive product decisions on a daily basis. Ultimately, they’re translating customer needs into actionable work items for the Development team.

The Scrum Master — This person is responsible for ensuring the team has everything they need to deliver value. They are a coach, counselor, advocate, impediment-remover, facilitator and mediator all rolled into one. They set up meetings and communicate progress and blockers. Hint: everything a project manager ought to be doing, just through the lens of scrum.

The Development Team — This is a group of cross-functional team members all focused on the delivery of working software. It is the singular noun for any developers, designers, QA and 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 especially at agencies, it might look a little bit different. The development team should to be self-organizing and motivated to provide value, and with proper facilitation by the Scrum Master and Product Owner, they can be.

Note: There are plenty of online resources and books for continued reading on scrum & the different roles. Let Google be your guide.

Each of these roles have unique participation in each of the scrum ceremonies. Through the application of these meetings, each member of the scrum team should be empowered to do their best work. Every meeting is time-boxed, intentional, and in service to the overall scrum team. In other words, they exist to make delivering software possible. Without further ado, let’s dive in.

Sprint Planning

What is it?

Sprint Planning is the scrum ceremony designed to make sure the team is prepared to get the right things done every sprint.

What’s its purpose?

This ceremony happens at the beginning of a new sprint and is designed for the Product Owner and Development Team to meet and review the prioritized Product Backlog. Through a series of discussions and negotiations, the team should ultimately create at a sprint backlog that contains all items they are committing to complete at the end of the sprint. This is called the sprint goal. The sprint goal should be a shippable increment of work, meaning it can be demonstrated at the end of a sprint. It needs to be agreed upon by the entire team.

The Product Owner is responsible for having the Product Backlog ready for review before Sprint Planning begins. This means adding acceptance criteria, requirements, and necessary details for the development team to accurately estimate the level of effort.The Product Owner also needs to be able to clarify any questions or assumptions that the Development Team has about the work. Only then can the development team accurately forecast the amount of work they can accomplish during the sprint.

Who’s in attendance?

The scrum team — product owner, development team & scrum master.

How long does it last?

The length of most scrum ceremonies 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). For example, if your sprint is 2 weeks long, the Sprint Planning ceremony should last no longer than 4 hours. For a 1 week sprint, it should last no more than 2 hours.

Are there any helpful tips?

  • User stories can be broken up into smaller tasks & assigned during sprint planning so that everyone knows what they’re held accountable to.

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 to arrive at the goal for each sprint.

Daily Scrum

What is it?

The Daily Scrum is the team’s chance to get together, define a plan for the day’s work, and identify any blockers.

What’s its purpose?

This ceremony provides a frequent opportunity for the team to get together and communicate individual progress toward the sprint goal. It’s not a status update. Instead, it should illuminate any impediments the team is having. The Scrum Master is responsible for clearing these roadblocks for the Development Team so they can focus on delivering the work identified in Sprint Planning.

During the daily scrum, each member of the Development Team should briefly answer the following questions:

  • What did you do yesterday?

Each participant in this meeting should be listening to each other and remain present through the entirety of the meeting. Often times, members of the Development Team will identify opportunities to work together during the day based on commentary during the Daily Scrum.

Who’s in attendance?

The Scrum Master and the Development Team. The Product Owner is an optional attendee. On occasion, outside stakeholders can be invited to listen in to the daily scrum.

How long does it last?

This one’s short! It should last no more than 15 minutes. Easier said than done.

Are there any helpful tips?

  • The ScrumMaster is responsible for keeping pace on this quick meeting. Consider setting a timer!

Anything else?

Alternatively named the daily standup or scrum meeting, this quick pulse check should set up the team well for the day. Don’t let it eat up too much time or it will have the opposite effect. This meeting enables to the team to be sync and build trust with each other. Let the team hold each other accountable for achieving their commitments on a daily basis.

Sprint Review

What is it?

The Sprint Review is the scrum ceremony where all work completed during the sprint can be showcased the stakeholders.

What’s its 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 see things sooner than later and inspect or adapt the product as it emerges. Sprint Reviews can be conducted in a casual “Demo Friday” nature or can be set up to be more structured. This all depends on several variables of the scrum team, such as product lifecycle and release planning.

Most importantly, all of the work showcased during this time should be fully demonstrable and meet the definition of done that the team is operating off of. The team should feel empowered to show off the work they’ve been able to complete over the course of the sprint. It should not feel like they are on trial or defending the work they’ve done. Rather, it should focus on the business value being delivered through product development.

Who’s in attendance?

The scrum team — product owner, development team & scrum master — and typically a mixture of management, outside stakeholders, customers, and even developers from other projects. In terms of who needs to be there, this scrum ceremony is more fluid than the others. The Product Owner and Scrum Master should be discussing who ought to be involved prior to the Sprint Review and work to ensure they’re in attendance.

How long does it last?

One hour per week of the sprint. As an example, a two-hour Sprint Review should be scheduled for a two week sprint.

Are there any helpful tips?

  • The Scrum Master assumes any administrative duties, ensuring meeting rooms are booked, additional presentation aids are available (like white boards or flip charts, for example), and that the meeting is appropriately timeboxed. Consider providing refreshments as well.

Anything else?

Alternatively named the Sprint Demo, this ceremony 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 eventually added to the product backlog. Do everything you can to let the team shine.

Sprint Retrospective

What is it?

The Sprint Retrospective is the final scrum ceremony in the sequence that allows the team to look back on the work that was just completed and identify items that could be improved.

What’s its purpose?

After a Sprint Review has been conducted, the scrum team needs to have the opportunity to reflect on the work that was just showcased and discuss ways in which to improve. The sprint retrospective is that meeting. It gives the scrum team a platform to discuss things that are going well, things that could go better, and some suggestions for changes. Some common questions asked are:

  • What went well over the last sprint?

Ultimately, this ceremony should provide a blameless space for members of the team to provide their honest feedback and recommendations for improvements. It should drive change. All actionable feedback should be collected and assigned so that members of the scrum team understand who is responsible for what.

Agile is all about constant improvement, and this ceremony is specifically designed to help the scrum team better.

Who’s in attendance?

The Scrum Master and the Development Team. The Product Owner is an optional attendee. There should be no outside stakeholders involved in the retro.

How long does it last?

Typically, retrospectives should last no more than 1.5 hours for a two-week sprint. If your sprints are a month, the retro should last no longer than 3 hours.

Are there any helpful tips?

  • Focus on continuous improvement and gather information that is based on facts, not just feelings.

Anything else?

If we’re getting technical, the sprint retrospective is not an official scrum ceremony. However, it’s a very common component of scrum and other methodologies because it and can help to identify areas of improvement and mitigate risk for future sprints. 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 & be respectful throughout the course of the ceremony.

What do you think?

Regardless of which project management tool you use or the product on which you’re working, these scrum ceremonies are designed to deliver results. I’ve found that these meetings certainly provide structure and go well when the team is all bought in with a shared understanding of what each ceremony is for. Again, scrum is just a framework to use to help deliver software in an agile fashion.

Every team is different, though, and there is no perfect process. The simplest advice I’ve heard is to keep the principles in mind! Think of your sprint ceremonies as product: keep iterating & improving.

Feel free to leave a comment below on your experiences running scrum ceremonies, and let’s learn from one another.

Originally published on thedigitalprojectmanager.com on May 6, 2018

Ideas by Crema

All of our thoughts and ideas.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store