Scrum Ceremonies and Artifacts: What Wasn’t in the Scrum Guide

The short answer to what scrum ceremonies are, is meetings. 

But these are not your regular team meetings where you come together and discuss some stuff, hoping that something useful eventually comes out of it. 

According to the scrum guide, the scrum framework has 5 events. These events are also called ceremonies. Scrum ceremonies are very specific meetings with clearly defined goals, participants, and time constraints. 

Without those scrum ceremonies, scrum simply doesn’t work.

If you take out any of the scrum ceremonies or radically modify them, you are no longer practicing scrum. Which means you won’t be a part of the 85% of scrum teams that improve the quality of their work and 62% of teams who successfully deliver projects using the framework.

In this article we’ll cover in detail the key 5 scrum ceremonies, what makes them so useful exactly, and the most common pitfalls that teams fall into when trying to implement them.

Whether knowingly or not, every scrum team also extensively uses scrum artifacts, so we’ll briefly talk about their role in the scrum ceremonies as well.

What Are the 5 Scrum Ceremonies?

These are the five key scrum ceremonies:

  • Backlog grooming (product backlog refinement)
  • Sprint planning
  • Daily scrum
  • Sprint review
  • Sprint retrospective

Apart from Backlog Grooming, the rest four ceremonies are meetings. As already mentioned, each one of these meetings has a special goal and timeboxing, so let’s cover them one by one. 

Scrum Ceremony #1: Product Backlog Grooming

Backlog grooming is the only ceremony in scrum that doesn’t have a defined time box or even a frequency. 

It is, however, a critical responsibility of the product owner with the help of their team to add new items to the list and order them based on their priority. 

At the same time, outdated, redundant or non-valuable items should be removed from the backlog to keep it clean, valuable and actionable. 

quickscrum.com

Sometimes teams make a meeting devoted to product backlog grooming to purposefully focus on this activity, but this is something every team decides for themselves. 

Bot the input for and the result of this ongoing grooming activity is the Scrum Artifact #1: Product Backlog.

Scrum Artifact #1: Product Backlog

The product backlog is a list of everything that is to be developed for your product or project. It can include new features, bug fixes, optimizations, or pretty much anything that somehow benefits the customer. 

If you have multiple scrum teams working on the same product, every team has their own sprint backlog, yet all the teams usually share the same product backlog. 

The product backlog needs to be constantly updated and refined based on stakeholders’ feedback, new ideas, sprint review meeting results, emerging market opportunities and so on. 

The more often you update and refine your product backlog, the more flexible, dynamic, and ultimately competitive your company will be.

Scrum Ceremony #2: Sprint Planning

All the work in scrum is cyclic: it happens during recurring, time-boxed periods when scrum team members are focused on delivering something of value to the customer. These iterative periods are known as sprints, and they have the same duration each time, somewhere between one week and a month. 

Sprints follow on one after another, without any pause between them. Every team sets the duration of their sprints themselves.

But to start a sprint, the team must know what they are going to develop. 

This is exactly what the sprint planning ceremony is for. 

The team gathers and starts to pull items from their product backlog into the sprint backlog. The team needs to carefully consider how many items to take on, as they will make a commitment to completing each item on the sprint backlog before the sprint ends. 

Which takes us to Scrum Artifact #2: the Sprint Backlog.

visual-paradigm.com


Scrum Artifact #2: Sprint Backlog

The sprint backlog is a list of items (also known as user stories) that the team is going to deliver during the sprint. During the sprint planning, the team selects the items in order of priority from the product backlog to form the sprint backlog. 

Teams usually break down sprint items into smaller chunks, known as tasks. That way they can share the work out among the team, and track their progress in a more granular way to ensure they stay on track to complete the item before the end of the sprint.  

Only the development team (NB excluding the product owner) can decide how many items they can commit to during the sprint, and only the scrum team (NB including the product owner) can make changes to the sprint backlog during the sprint. 

During the Sprint planning, the team takes into account their past performance, which allows them to more accurately forecast how many items they can finish. Team members should also account for other factors such as holidays and time-off, as well as other commitments that may reduce the amount of time they have. If it is the first sprint that the team has worked together (i.e. they have no past performance), they tend to go on gut feeling, or plan to only do small, simple tasks which they can more easily estimate in time. 

Only the development team can decide which items to take into the sprint, and while the product owner attends, nobody outside of the scrum team can participate in sprint planning meetings. 

“The more often you update and refine your product backlog, the more flexible, dynamic, and ultimately competitive your company will be.”

Finally, during sprint planning, the team also collaborates to choose a sprint goal, which helps team members to clarify the purpose behind this particular sprint. Choosing a sprint goal is key for a team’s productivity, so scrum teams should not neglect it.

Sprint planning summary:

  • Goal: to come up with the items and goal for the new sprint
  • Participants: the entire scrum team (developers, product owner, scrum master)
  • Frequency: once per sprint, at the start of the sprint
  • Duration: 2 hours for every 1 week of a team’s sprint duration

Common mistakes: letting people outside of the scrum team take part in the meeting, frequently changing the sprint’s duration, adding new tasks after the sprint is started (this is likely to happen during the daily scrum), not having useful data to be able to predict how many items you can take in.

Tips for effective sprint planning: experienced teams break down sprint backlog items into smaller chunks (tasks) to better evaluate how much time they need to finish them.

Scrum Ceremony #3: Daily Scrum

Daily scrums, or daily standup meetings, are a driving force for every sprint. 

The development team and scrum master gather each day for a very brief period of time (limited to 15 minutes) to discuss their current progress and any blockers that prevent them from finishing their tasks. The product owner can also attend to hear how things are going, and to offer guidance or clarification if the team needs it. But in essence the meeting is for the solution development team, and not an opportunity for the product owner to put more work on them, make decisions about how the team should work, or comment on the pace of progress.

Below are the three typical questions every development team member answers during a standup meeting:

  • What have you completed since the last meeting?
  • What do you plan to complete by the next meeting?
  • What is getting in your way?

The goal of daily scrum meetings is to look at how things are going and to make a plan for the next 24 hours that will keep the team on track to complete the work they committed to by the end of the sprint. 

Traditionally, standups are in-person meetings with team members physically standing in the same room. 

Standing forces team members to keep what they say to the point, which means the team can keep the meeting to the 15-minute timebox.  

Unfortunately, standing in the same room is impossible for distributed teams that practice scrum. This often leads to inefficient virtual meetings and in turn to a general distrust in Agile methodology.

Fortunately, remote teams can work around that with asynchronous daily standups.

For example, Geekbot automatically sends three standup questions to every team member directly in Slack, and then puts together all the replies in a designated channel.

This way team members can share their current progress within a minute and there is no time lost due to bad audio and video connections, for example. In case they need to discuss approach with other developers in the team, they can do that in threaded conversations involving just the people who are needed.  

Daily standup summary:

  • Goal: to share progress, check if they are still on track to successfully complete the sprint, and make a plan for the next day of work
  • Participants: Scrum team members (including the scrum master). Product owner is optional.
  • Frequency: daily
  • Duration: 15 minutes max

Common mistakes: having meetings longer than 15 minutes, discussing blockers or challenges during the standup (standups are for revealing problems; teams need to solve them after), team members seeing it as a report-out and not collaborating, skipping them completely.

Tips for effective daily standups: scrum master should be willing to tell team members when they are getting off-topic, talk about the items in order of priority (rather than just whoever wants to go first), use asynchronous standup meetings if your team struggles to keep daily standups focused and efficient. 

Scrum Ceremony #4: Sprint Review

The sprint review is a meeting that takes place at the end of the sprint.

The sprint review ceremony has three main objectives:

  1. Team demonstrates their finished work to the product owner and stakeholders
  2. Team discusses any feedback and business context for this project
  3. Team updates the product backlog based on the discussion

Many scrum teams tend to neglect items #2 and #3 and focus only on the demo part of the meeting, thus incorrectly referring to the sprint review as the “sprint demo”.

Yet discussing business context is crucial because it helps teams to decide what are the most valuable things to work on next. Those discussions may include market developments, user feedback, and company goals. 

Another important requirement is that, at the end of the sprint, work is finished and ready for the customer to use.

Which leads us to Scrum Artifact #3: Product Increment.

Scrum Artifact #3: Product Increment

A product increment is a new or updated, usable version of the product. 

In other words, it’s the tangible output of your sprint. A new feature, an updated interface, a new integration, or even a fixed bug can form part of a product increment as long as you can clearly demonstrate its value and apply the increment to your project.

Every product increment should satisfy the definition of done: a number of requirements that the team thinks a finished product should satisfy. For some teams the definition of done is simply “it works”, while for the other it’s a thorough list of tests and KPIs.

It’s also important for the team to test whether all of the items that make up the product increment work well together before releasing them.

Any half-finished work can’t enter the sprint review and should either be carried over into the next sprint (if its value is still high), or put back on the product backlog if the business priorities have changed.

Sprint review summary:

  • Goal: to present and discuss finished work, provide business context for future developments, and update product backlog
  • Participants: everyone (the scrum team, stakeholders, any interested party)
  • Frequency: once per sprint, at the end of the sprint
  • Duration: 1 hour for every 1 week of a team’s sprint duration

Common mistakes: focusing only on the presentation part, presenting unfinished work, showing screenshots or diagrams instead of working software, not inviting stakeholders to attend, not taking on board the feedback that is provided by the business.

Tips for effective sprint reviews: make sure your team members take time to prepare what they will show so stakeholders can easily understand their finished work and engage fully in the discussion.


Scrum Ceremony #5: Sprint Retrospective

Sprint retrospectives are critical for scrum teams that want to constantly improve the efficiency and quality of their work. 

All members of the scrum team attend sprint retrospective, which takes place after the sprint review. The team:

  1. Inspect how the sprint went in terms of people, relationships, process, and tools. 
  2. Identify what went well and opportunities for improvement.
  3. Create a plan with specific improvements to be carried out during the next sprint.

Step #3 is crucial and often neglected by inexperienced teams. In order to bring value, retrospectives need to be actionable. Simply uncovering areas of improvement without doing anything won’t bring results. 

Note: If you’re a remote team, you can
run sprint retrospectives directly in Slack with Geekbot.

Sprint retrospective summary:

  • Goal: to uncover opportunities for improvements and create a specific actionable plan to carry them out
  • Participants: all members of the scrum team
  • Frequency: once per sprint, after the sprint review
  • Duration: 45 minutes for every 1 week of a team’s sprint duration

Common mistakes: conducting non-actionable retrospectives or neglecting retrospectives altogether.

Tips for effective sprint retrospectives: focus on opportunities, not blaming other team members, vary the format so that it doesn’t become predictable and boring for the team members.

Summary

Scrum is a pretty fine-tuned machine that allows teams to constantly release value for their users while staying flexible enough to quickly respond to any changes happening in their market.

And as a car needs wheels to function properly, scrum needs ceremonies and artifacts. You can drive your car with three wheels but you won’t make it as far as if you had all four.

The same goes for scrum meetings and artifacts. Each one of them serves a highly valuable and unique purpose, and only together as a whole do they provide your team with unique opportunities for growth and success.

If you are a non-collocated team that struggles with making their scrum ceremonies efficient, try asynchronous meetings with Geekbot. 

Geekbot allows you to get the most value out of your daily standup meetings and retrospectives, keeping them sharp, distraction-free, and always on-point.

Leave a Reply

Your email address will not be published. Required fields are marked *