We have gone through three Scrum events so far - Sprint, Sprint Planning, and Daily Scrum. These three events cover the execution part of Sprint. But how do we end the Sprint? How do we demonstrate (and at times take sign-off) the work done during the Sprint? The answer to all these is the Sprint Review Event.
In this tutorial, we will go through the below topics.
- What is the Sprint Review?
- Who participates in Sprint Review?
- How to conduct a Sprint Review?
What is the Sprint Review?
The sprint review is a Scrum Event that takes place at the end of the Sprint to inspect the increment and adapt the product backlog.
The Sprint review allows all the stakeholders to inspect and adapt to what's already built. It provides a transparent view of the current state of the product, and gives a platform to ask questions, give suggestions, and have discussions on how to move forward based on the current situation.
Like every other scrum event, the Sprint review is also a time-boxed event. The duration is a maximum of 1 hour for every week of Sprint duration. So for a Sprint that is 2 weeks duration, the Sprint review meeting should be a maximum of 2 hours.
As a general practice, the Sprint review finishes on the last day of Sprint. It's important to note that the sprint review is not a "Demo". While the team showcases what they have done, the purpose is to collaborate as a group, take feedback, and decide on how to move forward.
Who participates in Sprint review?
As the purpose of the sprint review is to take feedback from the stakeholders, all the people who have a stake in the sprint deliverable must attend the review meeting.
Scrum Team
Scrum Team (Scrum Master, Scrum Development Team, and Product Owner) must attend the sprint review. They collectively need to collaborate with other stakeholders, and answer any questions and take feedback and next steps.
Internal Stakeholders
These are people within the organization that have a stake in sprint deliverable. These could be program managers, other scrum masters, marketing, sales, IT Support, Business development teams, etc.
External Stakeholders
Though it's not very common, the Product owner may invite people outside the organization for a sprint review. E.g., the team is enhancing a website where agents can book tickets for their clients. In such a case, the team can invite some agents so that they can have a first-hand look at the product, and they can provide feedback much early in the life cycle.
How to Conduct a Sprint review?
Sprint review has a larger audience, so it's vital that the meeting is planned well and executed well. We will have a look at the planning activities that need to happen before the review meeting. We will also look at the best practices and steps that need to finish during the meeting (execution)
Preparation Activities
These are the activities that need to finish before the sprint review meetings. It includes figuring out whom to invite, sending out the invites, confirming that all work is done, and planning for a demonstration.
1. Identify the Attendees
The first step in preparation is to identify who all needs to attend the sprint review. We know that the Scrum team is mandatory to participate in, but it's important to invite all the stakeholders. Usually, based on the broader goals that the team is trying to achieve, there will already be a set of stakeholders that will join every meeting. E.g., if the team is building an application that will collect user feedback for a product across all channels (FB, Twitter, emails, etc.), then the marketing team is a key stakeholder. They should be present in all the sprint review meetings. However, some sprint reviews need a specific set of stakeholders based on what we achieved during that Sprint. E.g., if the team has delivered capturing feedback via the emails that the IT support team gets, then just for that sprint review, the IT support team becomes a stakeholder.
In Summary, it's essential to identify all the stakeholders that need to attend the sprint review. It helps in early feedback, and also helps in easy acceptance and usage of the deliverable.
2. Sending out the invite
We have already identified the stakeholders, so we now need to send out the invites. The sprint review carries out on the last day of Sprint. Usually, the sprint duration is consistent (say two weeks), so the invite should be sent as a recurring invite every two weeks. It's also important to keep timing the same (say 4-5 pm of last day) and send it for weeks in advance. While this seems like a straightforward activity, it must be sent in advance and at the same time. It helps all stakeholders plan, and there will not be a request to re-schedule.
3. Are we done with all the work?
It's vital to confirm if all the work is completed (especially what was supposed to achieve last day) and update the Jira board (or any other software). It will help in presenting all the stakeholders with an accurate picture of what completes. You don't want to land in a situation where you say that it's finished but not reflecting on board.
If there is any work pending, that we should mark so that we can give a transparent view to all stakeholders that this work will slip to the next Sprint.
It's the responsibility of the development team to demonstrate ownership of the "Done" increment.
4. Prepare for Demonstration
It's essential to present the sprint review as ONE team. What this means is a clear plan and order in which the team will present. Usually, the Product Owner starts by talking about the goals of the Sprint and what functionality is delivered. The Scrum Master can show burn-down charts and the velocity of the team. After which the development team will showcase their work. It's always good to decide before-hand the order in which its presentation will happen and if we need to prep anything (E.g., setup any specific data, etc.).
It's also encouraged that most (if not all) team members get to present what they have achieved during the Sprint. It is not a good practice that 1-2 team members present the team's work.
Execution of the Sprint Review
Now we are done with all preparation activities. It's time to execute the sprint review meeting. There are best practices that need to follow to conduct review meetings effectively.
1. Summarize the work done in Sprint
The Sprint review starts with the Product Owner presenting the sprint goal set for this Sprint. PO also presents the backlog items that associate with this sprint goal. The product owner explains what Product Backlog items have their status as "Done" and "Not Done". This information gives a good view to all stakeholders of the achievement in this Sprint against sprint goals defined.
2. Demonstrate the Work
The development team will demonstrate the work whose status is "Done". They also talk about the challenges they faced and how they resolved them. The development team will answer any questions that the stakeholders may have on any of these work items.
At this point, it's essential that the discussions remain focused on the work at hand and not deviate from anything not relevant. Scrum Master needs to pitch in to park any such discussions and remind the team that it's a time-boxed meeting and demonstration of all the work that needs to complete.
3. Discuss and Adapt
The sprint review is an opportunity for a shared understanding between all the stakeholders - The people who create it (Scrum Team) and the people who benefit from it (End Users, Customers, and other stakeholders).
The product owner discusses the product backlog as per its current status. PO also presents the target dates and rough milestones on what will come up in subsequent sprints. The entire group deliberates on what to do no next. The basis of this discussion is what work needs to finish (including any spillovers from the current Sprint). As a group, the team discusses the priority items that we should take in the next Sprint. The stakeholders (like the Marketing team) could provide valuable insights into how the potential use of the product might have changed based on market conditions, and in that context, what makes the most sense to pick up next.
- The product owner will take this feedback and adapt the product backlog and prioritization accordingly.
- The Scrum Master can also talk about the team's velocity and how the team is improving every Sprint, which also feeds into how much work can finish in subsequent sprints.
- The sprint review meeting ends with a shared understanding between all stakeholders about the accomplishment of work so far, how much work is pending, and how the prioritization of work happens for upcoming sprints.
Common Questions on Sprint Review
Now that we have got a good understanding of the Sprint review event let's discuss some of the common questions and doubts that people have on Sprint review.
What happens if the Product Owner is not available during Sprint Review should we re-schedule to another day?
Ideally, the Product owner should always be present in the Sprint Review, but there can be instances where the PO cannot attend due to holiday or other reasons. In such circumstances, it's essential that the team still goes ahead with the review.
Remember - the Sprint review is not just about the Scrum team, it's also about all the stakeholders who are going to attend, so it's essential to keep the discipline and honor the time that everyone has committed.
The Scrum Master can take the lead to present the goals and calls out what to accomplish and what work is remaining. The team can take note of feedback that stakeholders may have on prioritization, and pass it on to the Product owner.
What happens if no significant work accomplished during the Sprint - Should we cancel the Sprint review?
Although not common, the possibility is that the team couldn't complete the work, and there is not much to show to the stakeholders. As such, it's common to think that the sprint review should get canceled, as not to waste the time of stakeholders.
However, it's important to note that demonstrating work is just one aspect of sprint review. Collaborating with a group on what to do next is another crucial aspect.
So in such a case, the team should still go ahead with the Sprint review. Discuss why the work couldn't complete. The team also needs to call out how they will incorporate the learning so they can do better next time. As a group, the team and stakeholders can deliberate on the prioritization of remaining work (including current spillovers). The Scrum Master can talk about velocity, to see if the work can still complete in the remaining sprints. Additionally, SM will check if there is a need for course correction (E.g., de-prioritizing some work, or adding additional team members, etc.).
