Sprint Reviews have three important goals: Prove It, Celebrate It, and Learn From It. These three goals have some inherent tension, so this episode will help you achieve all three while removing that tension.
In this episode, Richard and Peter dig into how to have an effective Sprint Review meeting. Great Sprint Reviews achieve 3 goals and answer 3 key questions. Learn how do accomplish this on your team. (And discover why “Sprint Demo” is too limited a name for this meeting.)
While this is explicitly Scrum-focused, it’s really about how to have a meeting to review a body of work as a team, whether you’re using Scrum or not.
Related Episodes
Why Scrum works when it works
Effective Sprint Planning
How To Have a More Effective Daily Scrum Tomorrow
Two Key Moves for Better Sprint Retrospectives
Episode Transcript
Welcome to the Humanizing Work Show!
Today’s episode is the fourth in our series about Scrum. If you haven’t yet, check out the first in the series on “Why Scrum Works When It Works,” which lays out our overall thinking about Scrum and how to use it well. We’ve also covered the Sprint Planning and the Daily Scrum meetings.
Today we’re talking about the Sprint Review and how to make yours more effective.
Before we jump into the episode, a quick reminder to rate and review the HW Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you.
The Sprint Review happens at the end of a sprint. It’s the meeting dedicated to reviewing, interpreting, and making decisions based on the change in the product during the past sprint.
Sprint Reviews have three important goals: Prove It, Celebrate It, and Learn From It. These three goals have some inherent tension, so this episode will help you achieve all three while removing that tension.
The Prove It goal is about encouraging accountability for the team’s commitment towards their Sprint Goal. Prove It helps build trust internally on the team and especially between the team and the rest of the organization.
The Celebrate It goal is about acknowledging the hard work of the team and celebrating their wins. Good Sprint Reviews build motivation and engagement by celebrating progress and small wins.
The Learn From It goal acknowledges that Scrum helps us better understand the right thing to build as we build it. Sprints are dual-loop experiments, and the Sprint Review is a chance to close the loop on the question “are we building the right thing”, then adapting our plans accordingly.
There is often tension between these three goals. For example, if we’re focused solely on the Prove It goal, we may feel uncomfortable acknowledging the uncertainty in what we’re building as we focus on the Learn From It goal. Similarly, if we focus completely on Celebrate It when the team only finished half of the items they pulled into a Sprint, we may avoid having important discussions about commitments and accountability.
There are two key moves to accomplish the three goals while removing the tension. The first is to frame the meeting through the lens of all three goals. For example, the ScrumMaster or Product Owner, whoever is facilitating the meeting, may start the meeting by saying something like:
“Welcome to the Sprint Review. Today we have three goals. First, we want to give the team a chance to demonstrate several changes that are ready to release today. The team ran into a few challenges with a few of those items and we want to celebrate the awesome work they did. Second, we want to talk briefly about a few of the challenges they ran into with two of the items that didn’t get done and our plan for addressing those challenges in the next Sprint. Finally, we want to zoom out a bit and get some feedback about how the work of this Sprint fits into our team and business goals.”
Notice in this framing, the facilitator went from Celebrate It to Prove It to Learn From It. That’s often a good move when the team doesn’t finish everything they pulled in during Sprint Planning.
The second key move in resolving that tension is to look at the product at 3 levels of detail, answering 3 big questions (or, to put it a little differently, closing 3 feedback loops).
At the highest level of detail, a team should be reviewing the major ways the product has changed in the last sprint, with the goal of getting info to help answer the question, “Are we going in the right direction?” For a software team, this level means focusing on features completed during the past sprint, which may have been worked on across multiple sprints. For a non-software team, this’ll be some other larger product increment that could have spanned a sprint or two. This level will include your most senior stakeholders. Feedback generated here is mostly for the product owner and informs the future product backlog and other customer research that happens outside the product backlog.
At the next level of detail, a team is trying to answer the question, “Are we making progress on the next major product increment we intend to deliver?” For a software team, this level means focusing on user stories. By the time you get to this level in the Sprint Review, your more senior stakeholders may have left the meeting, and you may just have the team and closer stakeholders in the room. Feedback at this level informs both the product owner as well as the developers.
Finally, the third level of detail looks under the covers at the product and asks, “How has the internal quality of the product changed over the past sprint?” This will be informed by the team’s definition of done and whatever measures they use to assess the quality of the product. Here, the team is trying to get early indicators of issues that may affect the sustainability of the team. By this point in the meeting, it’s often just the Scrum team or even just the developers in the room. Teams often use insights gained here to inform the upcoming Sprint Retrospective.
To recap…
- An effective Sprint Review should focus at 3 levels of detail to answer 3 key questions:
- At the level of larger changes in the product, such as features on a software team, review the change and get feedback to help answer the question, “Are we going in the right direction?
- At the level of more granular changes, such as user stories, review the changes and get feedback to help answer the question, “Are we making progress on the things we intended to do?”
- And under the covers of the product, ask, “How has the internal quality of the product changed over the past sprint?”
- Make sure you have the right people in the room for each of levels. It’s ok if the meeting gets increasingly smaller as you move from one level to the next.
- Within each of the 3 levels, an effective Sprint Review should accomplish 3 things:
- Prove it to encourage a strong focus on commitments and accountability, building trust over time.
- Celebrate it to acknowledge the great work being done by the team, even in Sprints where everything didn’t go as planned.
- Learn from it, acknowledging that most of the work we do has some uncertainty and that the best way to address that uncertainty is to build small chunks that we can observe, inspect, and adapt.
If you’re on a Scrum team, ask yourself, “Does our team accomplish all three goals during the Sprint Review? Do we address each of the 3 levels of detail in our Sprint Reviews? Do we do it in a structured, deliberate way? Do we have the right people in the room for each level of detail?”
What is the hardest part about Sprint Review for you? Let us know in the comments on YouTube if you’re watching this episode there, or shoot us an email at mailbag@humanizingwork.com to let us know. Thanks for tuning in and as always, like and share the episode if you found it helpful!
Learn More About Scrum
Certified Scrum Product Owner Workshop (virtual, instructor-led)
Certified ScrumMaster Workshop (virtual, instructor-led)
Agile & Scrum Crash Course (online, self-guided)
Last updated