There are five events in Scrum and all five Scrum events are essential to the proper execution of Scrum. Like an orchestra who maintains the right beat throughout its performance, the five Scrum events support Scrum teams in properly executing their work. And the Scrum Master is the orchestra director on the Scrum team, providing the beat that makes the five Scrum events effective.
Scrum is one of the most common frameworks implemented in Agile. In the article “What is Scrum?” we talk more about its origins and fundamentals. In this article we do a deep-dive on the five Scrum events.
Let’s start with a quick overview of the Scrum workflow:
In this article, we provide a deep dive of the 5 Scrum events: the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. For each event, you’ll find a summary table describing the timebox, the purpose, the participants, and the expected outcome of the meeting. You can also download the whole PDF document (see link at the bottom).
Sprint
The Sprint sets the heartbeat for the whole Scrum team. It provides the cadence and structure for the team to follow. The Sprint is an iteration with a maximum duration of one month, and often teams choose a shorter timebox (most of the teams I work with use 2-week Sprints). The Sprint supports sustainable pace and allows the team to perform their work incrementally and iteratively. All the other Scrum events are contained within the Sprint.
A Sprint starts always on the same day of the week (or of the month) and every Sprint has the same duration. The Scrum team decides how long their Sprints should be (for example, 2 weeks) and then all Sprints have the same duration. Sprints cannot be shortened or extended just to fit the work in. They just end when the timebox is over, and a new Sprint is started immediately after the previous one.
Sprint Planning
At the beginning a new Sprint, before we can do any work, we need to plan what we are going to work on. Sprint Planning provides the structure for the team to define its goal for the Sprint (the Sprint Goal), the list of work items selected for execution during the Sprint (the “What” in the Sprint Backlog), and the plan on how the team is going to execute the work (the “How” in the Sprint Backlog). Three important activities take place at Sprint Planning:
Activity #1: Setting the “Why”
At Sprint Planning, the Scrum Team, working collaboratively, decides the Sprint Goal. This is the objective that we are setting up for ourselves and that we want to achieve by the end of the Sprint. All the work we will do in the Sprint should align to and allow us to achieve the Sprint Goal. The Sprint Goal provides the “Why” (why we are doing the work), and gives guidance to the Developers as to where to focus their efforts.
Activity #2: Setting the “What”
The Product Owner provides guidance and context on the most important work to do in the Sprint and shares a list of priority items selected from the Product Backlog.
The Developers, having established their capacity for the Sprint, decide how many of the work items proposed by the Product Owner they can effectively commit to complete within the Sprint. (Read this article for more information on capacity and velocity). The Developers can push back on excessive demands from the Product Owner if they feel that the work requested does not fit within the available capacity for the Sprint. The goal here is for the Developers to set a reasonable commitment for the work they can get 100% completed in the Sprint.
Ultimately, the Developers select a list of work items (PBIs, Product Backlog Items) that they are committing to deliver this Sprint, and put them in the Sprint Backlog. The commitment should not be taken lightly: it is important for the Developers to select the right amount of work they can effectively complete 100% by the end of the Sprint. This is not about setting unreasonable expectations, nor is about setting stretch goals. The commitment here is a signal to the Product Owner (and the rest of the stakeholders) on what they can expect the team will deliver by the end of the Sprint. By setting the right expectations, and committing to deliver on these expectations, the Scrum team builds trust with the rest of the organization.
On the other end, the commitment should not be punitive if not met: we all live in reality and unexpected events and circumstances always happen. And if the team is not able to complete all the work 100% by the end of the Sprint, be it: we learn, we adjust our capacity measures, and we will do better in the next Sprint. However, this should not be an excuse for not meeting the commitment all the time. The expectation should be that whatever the Developers select in the Sprint Backlog, they will deliver 100% by the end of the Sprint.
Activity #3: Setting the “How”
Finally, the Developers create a plan on how to execute the work. They look at the work items selected for the Sprint Backlog, and decide how to execute the work: who is doing what? Do we need extra help from external teams? Do we have dependencies to account for? Do we know how to do the work? Etcetera.
At this point, the Product Owner may not be very active in the conversation as the Developers mainly discuss how to execute the work. However, it’s useful for the Product Owner to participate as he or she may answer questions that the Developers may have about the work itself or about the expectations for the Sprint.
This plan represents the “How” and it also goes in the Sprint Backlog.
Daily Scrum
The Daily Scrum is an opportunity for the Developers to get together and inspect their progress towards the Sprint Goal. They do this every day, to keep track of their progress and to identify what to do in order to complete the Sprint Goal.
At the Daily Scrum the Developers should answer these questions: How are we doing? Are we on track to deliver the Sprint Goal and complete the work on the Sprint Backlog by the end of the Sprint? Are we late? Do we have impediments that are stopping us from completing the Sprint Goal? What needs to happen today in order to move forward toward the Sprint Goal?
The Daily Scrum is timeboxed to 15 minutes to keep the conversation focused and avoid lengthy discussions.
If the Developers need to sync with each other, talk with the Product Owner, or analyze possible solutions to problems they are facing, they can have these conversations AFTER the Daily Scrum. In fact, the Scrum team works together all day, so besides the Daily Scrum, they have 7 more hours and 45 minutes every day to sync up and discuss solutions.
This means that the 15 minutes at Daily Scrum can be focused on inspecting progress toward the Sprint Goal and updating the plan on what to do today to advance toward completing the work.
The Scrum Master is optional: if the Developers need help facilitating the Daily Scrum, the Scrum Master can support it. For example, the Scrum Master may want to make sure everyone understands the purpose of the event, and the Scrum Master may offer ideas on how to run the meeting. For example, the Scrum Master may offer 3 questions that everyone answers (as examples, choose from those listed above). Or the Scrum Master may suggest to do PBI-by-PBI Review in front of the Sprint Backlog to focus the conversation on the work to be done. In any case, the Scrum Master should not direct the meeting, nor be on the receiving end of the discussion: the Daily Scrum is for the Developers to talk to each other, and no one else.
The Product Owner is also optional: it may be helpful for the Product Owner to listen in and get a sense of how things are going for the Developers, what to expect (or not) by the end of the Sprint, and if the Developers need any help in understanding the scope of work. The Product Owner also should not be on the receiving end of the conversation: the Daily Scrum is for the Developers, and the Product Owner (when present) is a silent observer. Again, any conversation or further discussion with the Product Owner can take place throughout the day, AFTER the Daily Scrum.
Sprint Review
At the end of the Sprint, the work that the Developers selected in the Sprint Backlog should be completed, and the Scrum team can present the Increment they created to the stakeholders for inspection and adaptation. The Sprint Review is held on the last day of the Sprint.
The Sprint Review is an informal meeting where the Scrum team and the stakeholders (and customers, when possible) inspect what was accomplished during the Sprint and provide feedback to the Scrum team. Ideally, the stakeholders get an opportunity to use the product Increment, play with it, test it, and provide feedback about their experience. This is much more than a “demo”, and it’s more a working session based on collaboration. The goal of the Sprint Review is to get feedback from stakeholders, validate the Increment, and provide transparency on status.
As a result of the discussion, the Product Backlog and the release plans are adapted to reflect what the team learned, optimize the value delivered in the next Sprint, and decide whether to release or not. This increases transparency.
It is essential that stakeholders participate at Sprint Review. Their feedback on the work completed and on the plan for what to do next is essential. And also, this is an opportunity to get status on how the work on the product is progressing. In fact, I always recommend to stakeholders that, if they want to know the status of the work the team is doing, they should come to the Sprint Review. This is THE opportunity for stakeholders to interact with the Scrum team, evaluate progress on the product, provide feedback, and decide next steps.
Sprint Retrospective
On the last day of the Sprint, after the Sprint Review and before closing off the Sprint, the Scrum team holds the Sprint Retrospective. This is the opportunity for continuous improvement of the Scrum team.
At the Retrospective the Scrum team inspects how it works together. This is not about the work it produced (the Scrum team already inspected it, at Sprint Review together, with the stakeholders). Rather, the Retrospective is about how the team works together, what processes it uses, what team rules and behaviors to enforce, how to support team happiness. This is the opportunity to reflect on how the team members work together, and what they can do to improve as a team.
I like to use these rules to conduct a good Retrospective:
- Identify and discuss both what went well and what could be improved: celebrate successes, and then look at how to improve
- The Scrum Master ensures the Retrospective takes place, but no obligation to facilitate it: other team members can facilitate it (rotational basis) or another Scrum Master can do it for your team
- Spend at least as much time planning the Retrospective as you spend doing it, to ensure you can focus the Retrospective on an important area for improvement, rather than a generic conversation
- The Scrum Team discusses possible solutions to most vexing problems as opportunity for improvement. Just talking about problems does not help anyone. Discuss possible solutions and decide what to do to improve.
- One or more action items are identified and placed in the Product Backlog, or even better, scheduled for the next Sprint. This is a way to make sure action takes place, and improvements don’t remain just words.
- The facilitator frequently changes exercise or framework to run the Retrospective. Don’t make every Retrospective be the same, because, let’s be honest, how many new ideas for improvement can you really get if you always run it the same way? There are hundreds of Retrospective exercises to experiment with. For some ideas, look at Tasty Cupcakes.
Overview of the five Scrum events
To summarize our discussion on the five Scrum events, we have prepared an overview of the Scrum events. In this table you can find quick information about each of the meetings, with summary information about the purpose, participants, and outcomes of each of the events.
Use it to create alignment with your team, or as a practical hand-out when you run the Scrum events.
Download the PDF
You can download the PDF document, print it, or keep it handy for use with your team when your run the Scrum events. Visit the download page.
