The Scrum Guide states the following about Sprint Review: The purpose of the sprint review is to inspect the outcome of the sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the product goal is discussed. During the event, the Scrum team and […]
The Scrum Guide states the following about Sprint Review:
The purpose of the sprint review is to inspect the outcome of the sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the product goal is discussed.
During the event, the Scrum team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The product backlog may also be adjusted to meet new opportunities. The sprint review is a working session, and the Scrum team should avoid limiting it to a presentation.
The sprint review is the second to last event of the sprint and is timeboxed to a maximum of four hours for a one-month sprint. For shorter sprints, the event is usually shorter.
Thus, the sprint review is a critical event in Scrum that allows our customers, users, and stakeholders the opportunity to inspect the product increment and provide feedback. Below are some common questions regarding sprint review:
The sprint review is hosted by the Scrum team (Product Owner, Scrum Master, and Developers). From there, they can invite end users, customers, subject matter experts, stakeholders, members of leadership, people from other teams, and basically anyone they want to give feedback on the product.
I recommend all the developers attend sprint review. This way they can all hear and see the same feedback. They can help answer questions, help provide insights, and help show off what they have built. Additionally, since the previous sprint is over and the next hasn’t started yet, there is theoretically no planned work (or at least no active sprint backlog yet).
As proclaimed by the Scrum Guide, the purpose is to inspect the outcome of the sprint and determine future adaptations. What this means is that the sprint review is the event in which we get feedback from users, customers, stakeholders, and others to ensure the team’s product meets the user’s needs.
I’ve seen sprint reviews devolve into project management checklist. For example:
“Welcome everyone to sprint review. For this sprint, our goal was 80 story points. User story #1: did we finish it? Yes, we did, and it was 13 story points. User story 2: did we finish it? No, why not? It was 5 story points. User story 3: did we finish it? Yes, we did and it was 8 story points…”
That scenario is NOT what sprint review should be focused on. Ultimately, sprint review is about inspecting and adapting the product, not a project management checklist.
The sprint review occurs at the end sprint, but before the retrospective. The reasons it occurs before retrospective is that the outcomes from the sprint review are data points the team should use in the retrospective.
Here’s the potential issue if the team performs the retrospective prior to sprint review:
The team completed the sprint and the sprint went great. The gprint Goal was met, they completed all the user stories and story points, and the Product Owner approved the increment. In the retrospective, they all agreed it was a great sprint and simply celebrated that. However, in sprint review, the feedback was that the users hated what was built and on top of that it was glitchy. The team now needs another retrospective to reflect on those points.
Suppose the sprint review was indeed the first time the Product Owner saw the updated product increment. The Scrum team is in sprint review with their users, customers, stakeholders, and leadership. The team presents the product and the Product Owner says, “What is that? That is not what we agreed to.” The team responds with, “Well, that’s what the user story says and it’s exactly what we agreed to.” The Product Owner then says, “I wrote the user story, it wasn’t supposed to look like this.”
If the team has that back and forth in front of their users, customers, stakeholders, and leadership, it creates confusion and a lack in confidence in the team. If that conversation was necessary, it should have happened during the sprint. The Product Owner should be reviewing the completed items throughout the sprint. On top of that, I recommend that the Product Owner, Scrum Master, and Developers have a quick synch up prior to sprint review. This ensures it is a smooth and seamless experience for the attendees giving the feedback.
The Scrum Guide doesn’t dictate who must facilitate sprint review. It can be the Product Owner, Scrum Master, Developers, or even someone outside the team.
However, I do have some recommendations. Since your Scrum Masters are generally going to be good facilitators, you can start off having them run the session. As the team gets more mature, I like having the Product Owner kick off the sprint review by explaining the sprint goal. Then, they can pass off to the Developers so they can show what has been built. From there, ideally, we want the attendees to be able to interact with what has been built. Since the Developers are presenting, the Product Owner can soak in the feedback, take notes, answer questions, and provide insights. This is harder to do if the Product Owner is also facilitating the session.
The guidance from the Scrum Guide is no more than four hours for a month-long sprint. Thus, for a 2-week sprint, the guidance is two hours or less.