A Practical Guide to the five Scrum Events

By Don't Panic
Scrum events

Scrum is simple. Indeed, it is a very lightweight framework everyone can understand. However Scrum is purposefully incomplete: It just defines the rules of the game, like the rules of a sport. You need to know the rules well to play a certain sport, but knowing them is not enough to win a championship. That’s one reason why Scrum is hard to master: you need to know so many things outside Scrum to make it work successfully. Since Scrum is based on empiricism, a key success factor is how well a team runs their Scrum Events, which represent an opportunity to inspect and adapt either the product or the process. 

In this article, we will give you some practical suggestions on how you can make them work effectively, which you will not find in the Scrum Guide. And even if you are not using Scrum, you will be able to apply what you learn here to other contexts. 

What are the Scrum Events?

There are five Scrum Events, namely the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. In this article we will take a deep dive into each of the Scrum Events that happen within a Sprint. In Scrum, the Sprint is a fixed length event of maximum one month, which contains all other events. 

Scrum online course

Scrum Events or Scrum Ceremonies?

The Scrum Events are often also called “scrum ceremonies”. This was a term used in the 90s and probably borrowed from some other agile framework, but it never appeared in the Scrum Guide, where the official term has always been “scrum events”, since its first version published in 2010.

Sprint Planning

The Sprint Planning event takes place on the first day of the Sprint. Its purpose is to plan the work to be done during the Sprint and the whole Scrum Team is involved in this event. Sprint Planning should have roughly three parts. Topic One should focus on the “Why?”. The outcome should be a defined Sprint Goal. Topic Two covers the “What?”. During this topic, the developers should work to decide which Product Backlog Items are going to be worked on during the Sprint, and if necessary, refine the Sprint Goal to reflect this. Finally, Topic Three deals with the “How?”. During this final stage of the meeting, the developers create an actionable plan to get the work done. 

Sprint Planning meeting

When: The first day of the Sprint.
Duration: The Sprint Planning should be a maximum of eight hours for a one-month Sprint. For shorter Sprints it is usually shorter, roughly four hours for a two-week Sprint. A good Scrum Team is usually able to plan a two-week Sprint in less than three hours.
Participants: The whole Scrum Team participates in this event: Product Owner (PO), Developers, and Scrum Master (SM). The event is usually facilitated by the Scrum Master. Other people may be invited by the Scrum Team, including anyone who can contribute to plan the Sprint, for example stakeholders, users or specialists from other teams.
Input: A well refined Product Backlog (PB) with an adequate number of ready Product Backlog Items (PBIs)
Output: The Sprint Backlog, consisting of the Sprint Goal (Why), the list of items pulled from the Product Backlog (What) and a plan for how to achieve the Sprint Goal and deliver the Increment (How)

How to run a Sprint Planning event

  1. Introduction
    The Scrum Master, who acts as facilitator, introduces the event by welcoming the participants, explaining the purpose of the meeting to the people invited by the Scrum Team and showing the agenda for the meeting. (5-10 min)
  2. Topic One: Why?
    The Product Owner takes the lead, provides an overview of the Product, and reminds everyone about the long-term aim for the Product as well as the current Product Goal. They come prepared and propose a draft Sprint Goal. For example, assuming that we are in a payment domain, a Sprint Goal could be: By the end of the Sprint, we will support card payments for all EU customers. (10-15 min)
  3. Topic Two: What?
    The Product Owner and the Developers quickly go through the Product Backlog. The Developers should have contributed to refining the Product Backlog, spending “just enough” time to do some final clarification and possible changes after the last Product Backlog Refinement session. (30 min)The Developers make a forecast of how much capacity they think they can spend on building the Increment during the Sprint and then select a list of PBIs they believe they can complete by the end of the Sprint. If those PBIs seem to be sufficient to achieve the Sprint Goal proposed by the PO, this part of Sprint Planning is complete. Otherwise the PO and Developers collaborate to craft a new Sprint Goal which better aligns with what the Developers can deliver. In the example above they might come up with something like: By the end of the Sprint, we will support only debit card payments for all EU customers. (15-30 min)
  4. Topic Two: How?
    The Developers collectively create an actionable plan to deliver the Increment. They self-organize on how to best achieve that. It is not necessary to create a detailed plan for the Sprint. Instead, the Scrum Team should anticipate emergent opportunities and be prepared to adapt their plan as they learn. It is probably enough to have an idea of what each Developer will do in the coming 2 to 3 days. In this phase of the Sprint Planning the PO is not really necessary. However it is good if they are available to answer questions or clarify customer needs. (30-45 min)
  5. Closing
    The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)

Tips for Sprint Planning

The Sprint Planning is not supposed to be a “surprise party” for the Developers. It is not meant to be the first time they look at the PBIs which are candidates to be pulled into the Sprint. Developers usually spend 10% of the Sprint capacity to work on refining the PB and look ahead at what might come in the next Sprints. Otherwise the risk that the Sprint Planning becomes an endless death march is very high.

Scrum master certification

Daily Scrum

The Daily Scrum is the moment where the Developers step back for 15 minutes, analyze where they are in respect to the Sprint Goal, and collectively decide what is the most important thing each Developer has to do in the next 24 hours to get closer to the Sprint Goal. It is a planning meeting, not a generic synchronization meeting. If your Developers are waiting for the Daily Scrum to speak to each other, you have a problem. 

It is important to focus the conversation on the most important Sprint Backlog Items, not on individuals stating what they have done. The Daily Scrum is not a status report meeting. The SM should help create the right environment to encourage open communication, identify obstacles, and promote quick decision-making.

Daily Scrum

When: Every working day at the same time
Duration: A maximum of 15 minutes
Participants: The Daily Scrum is the only event that is self-managed by the Developers. The role of the SM is to teach and coach the Developers to run it autonomously.
Output: An adapted Sprint Backlog, if necessary
Structure: The Developers decide how they want to run it

Tips for the Daily Scrum

It is usually not necessary that the PO attends the Daily Scrum, but it is also not forbidden. Even if the PO is not directly involved in planning how to build the Increment, the Daily Scrum can be a good moment to check how things are going and offer help to the Developers.

Sprint Review

The Sprint Review is an opportunity for the whole Scrum Team to stand in front of their users, stakeholders and customers and inspect and adapt the Product. It takes place at the end of the Sprint. The meeting should include an overview of the state of the product in terms of progress, budget and next steps. Usually, there is also a hands-on demonstration of the actual product. The users and stakeholders provide feedback, and then the developers incorporate relevant feedback into the Product Backlog.

Sprint Review

When: Last day of the Sprint
Duration: A maximum of four hours for a one-month Sprint. For shorter Sprints it is usually shorter: roughly two hours for a two-week Sprint.
Participants: The whole Scrum Team: (Product Owner, Developers, Scrum Master) as well as the customers, stakeholders and users. The event is usually facilitated by the Scrum Master.
Output: A revised Product Backlog and changes to the product or release strategy, if necessary
Structure: An inspection phase followed by an adaptation phase (working session)

How to run a Sprint Review

  1. Introduction
    The SM, who acts as facilitator, introduces the event by welcoming the participants. They explain the purpose of the meeting to the participants which can include users, stakeholders and customers. Then they show the agenda for the meeting. (5-10 min)
  2. Inspection phase
    The PO takes the lead and provides an overview of the state of the product in terms of progress, budget and next steps. They remind everyone of the Product Goal and describe the Sprint Goal the Developers were trying to achieve. (10 min)
    The PO leaves the stage to the Developers to demonstrate the Increment. This is not a PowerPoint presentation of what the team has done, but a hands-on demonstration of the actual product. Usually Developers will go through the scenarios described in the acceptance criteria of each PBI. Some teams even let users or customers try the product themselves, while the Developers and the Product Owner observe how they interact with the Increment. (30 min)
    The Scrum Team collects feedback on the Increment from all invited participants. (15-30 min)
  3. Adaptation phase
    Users, stakeholders and customers might leave the meeting at this point, while the Scrum Team continues with a working session to incorporate relevant feedback into the Product Backlog. Should the feedback be related to something which does not impact the upcoming Sprint, they can simply take notes to address the feedback in one of the upcoming Product Backlog Refinement sessions. However, if the feedback potentially affects the next Sprint Goal, the Scrum Team will perform a quick Product Backlog Refinement session during the Sprint Review to get ready for the upcoming Sprint Planning. (30 min)
  4. Closing
    The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)

Tips for the Sprint Review

The Sprint Review should not be a “surprise party” for the PO, who is supposed to collaborate with the Developers throughout the Sprint. The whole Scrum Team is accountable for delivering a valuable and usable Increment at the end of each Sprint.

Sprint Retrospective

The final Scrum Event is the Sprint Retrospective. The Sprint Retrospective is the only event in Scrum that is exclusive to the Scrum Team. The intention is to create a safe space where everyone in the Scrum Team feels comfortable to openly share their observations and express their views and ideas. The purpose of the event is to inspect how the last Sprint went and plan ways to increase quality and effectiveness.

Related reading: 11 ways to improve your Retrospectives

Sprint Retrospective

When: Last day of the Sprint, right after the Sprint Review
Duration: A maximum of three hours for a one-month Sprint. For shorter Sprints it is usually shorter.
Participants: Only the Scrum Team: Product Owner (PO), Developers, Scrum Master (SM). The Scrum Master usually facilitates the event
Output: An improvement plan
Structure: A good structure is suggested in the book “Agile Retrospective – Making Good Teams Great” from Esther Derby and Diana Larsen, which comprises the following 5 steps:

  1. Set the stage
  2. Gather data
  3. Generate insights
  4. Decide what to do
  5. Close the retrospective

How to run a Sprint Retrospective

  1. Set the stage
    The SM, who acts as facilitator, introduces the event by welcoming the participants and showing the agenda for the meeting. They work to create the right environment for focused and open communication. Maybe it was a tough Sprint, with conflicts and failures, and it is essential for the team to step back from the stress and consider different perspectives to find opportunities for improvement. (5 min)
    Here is a simple yet effective activity you can do. Ask every individual to write on one sticky note the worst thing going on in their head at the moment and on another sticky note what would make them happy after the event. Then ask them to throw away the first sticky note and keep the second one.
  2. Gather data
    Now it is time to gather both objective (e.g. number of found bugs) and subjective data (e.g. how the different people felt throughout the Sprint) from the Sprint. (10-15 min)
    Sometimes it is hard for people to recollect data after a few weeks. Consider asking everyone to report events when they happen (for example by adding sticky notes on a Miro board) with a short description and a time stamp. During the retrospective you can look at the sticky notes and order them on a timeline. Then each individual visualises their mood related to those events. Then you have both objective and subjective data in a single visual artifact.
  3. Generate insights
    Now it is time to look at data and try to find patterns. These will allow the team to identify one or two improvement areas. (15-30 min)
  4. Decide what to do
    Once the most important improvement area is identified, the team collaborates to define a few actionable items to incorporate in the next Sprint. Consider those items experiments. Once the team validates they actually lead to a positive impact, they can incorporate them into the team’s routines and practices. Using the SMART technique enables the definition of action items which are Specific, Measurable, Attainable, Relevant and Time-bound. (30-45 min)
  5. Close the retrospective
    The Scrum Master thanks the participants for their contribution, closes the event and encourages everyone to celebrate the Sprint. In an in-person setup, this might be a good moment for the PO to share a cake to thank everyone for their effort. (5 min)

Tips for the Sprint Retrospective

The most impactful improvements are addressed as soon as possible. They may be added to the Sprint Backlog for the next Sprint and usually 10% of the Sprint capacity is allocated to address those improvements.

Whether the PO should participate in the Sprint Retrospective or not has been debated for a long time. In the last few years, it has been agreed that the PO must participate in the Sprint Retrospective because they are not the boss of the Scrum Team but part of it and on the same level as SM and Developers. Retros typically include conversations around how to refine the Product Backlog or how to collaborate with the customer, which are part of the PO’s accountability.

The Scrum Master usually facilitates the Sprint Retrospective, but can also decide to participate in discussions. An example might include sharing observations about how the Scrum Team is running the Scrum Events. In that case it’s a good idea to ask another person to facilitate. This could be one of the Developers or a Scrum Master from another team.