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:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
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.
- Encourage the team to sketch out tasks, bugs, and any item that requires it during this meeting. It should be an extremely collaborative ceremony.
- Once a sprint goal is set, it should not be interrupted by competing work. However, the Product Owner can cancel the sprint if the goal is no longer relevant.
- Stick to your timebox. Keep your eye on the clock, and once you?re at time, stop.
- Be sure to keep in mind any time off, vacations, holidays, or other scheduling details during the sprint to accurately reflect the amount of work that can be accomplished.
- Similarly, try to have a measure of the team?s velocity before Sprint Planning begins.
- Remember: You?re planning for a sprint, not a marathon! Try not to get sidetracked by items that haven?t been determined ready by the Product Owner.
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?
- What will you do today?
- Are there any impediments in the way?
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!
- Hold the meeting at the same time each day of the week (typically in the mornings), and do what you can to make this as routine for the scrum team as possible.
- If your team is distributed, leverage video conferencing software so the team can still see each other.
- For live stand-ups, consider throwing a ball around the room to indicate who should be speaking at any given time.
- If (or truthfully when) something comes up in this meeting that warrants a longer conversation, encourage the team members to sync up as soon as the Daily Scrum wraps up to determine when they want to collaborate. It could be immediately after the meeting or later in the day. Again, let them self-organize.
- There are tools and Slack integrations, such as Geekbot, that allow standups to happen asynchronously. While those can be helpful in certain circumstances, it is encouraged that these meetings happen in person or over a video call.
- The tone should be light and fun, but with a focus on collecting and communicating information.
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.
- Actionable feedback received during the Sprint Review should be converted into new product backlog items for later prioritization and discussion.
- Preparing for this meeting is a good idea! Since stakeholders from outside the scrum team are often in attendance, be sure to build in any rehearsal time or other preparation necessary to set the team up for success.
- Focus the Sprint Review around user experience and business value. It should not feel like the Development Team is just proving that things work.
- The Product Owner should be asking questions to the stakeholders, gathering feedback, and also providing answers to any that arise
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?
- What didn?t go so well?
- What could we do differently to improve?
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.
- Keep things novel, and consider different ways to engage the team during this ceremony. There are a host of resources out there that provide examples to make these meetings more effective. One example can be found here.
- Generate meaningful insights from the conversation. If you sense there?s more to be said between the lines, encourage team members to go deeper.
- 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.
- Create a space where the conversation more easily flows. Consider bringing in food, colored markers, sticky notes and other things to encourage participation.
- Revisit previous suggestions to determine whether the team should keep doing them.
- Build the team?s ability to self-organize.
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
