What Is A Sprint Review
The Sprint Review is a discussion at the end of a sprint intended to review what the team accomplished in the sprint (including demonstrating done functionality), get feedback, and determine what, if any changes should happen in the team’s plan moving forward.
These changes usually consist of revisions to the product backlog or guidance into what the team does in the subsequent sprint.
The exact agenda of a sprint review depends on what your stakeholders expect and any standards your organization has.
Here’s an example Sprint Review agenda for a team I worked with recently. We included some of this information because stakeholders in the organization requested it. I’m not sure if I would cover these items in this exact format if I were left to my own devices.
As a result of request from stakeholders, we place the information in a Powerpoint:
- Backlog Items Completed
- Points and Items completed – Bar Chart
- Work Breakdown – Percent Points per “big chunk” (Epic) – Pie Chart
- Item Type – Percent of Item count by feature, bug, or data update – Pie Chart
- Bar Chart showing Target Velocity and Actual Velocity
- Screen shots of key items to demonstrate
- Backlog Items planned for next sprint
When to Do A Sprint Review
You generally do a sprint review when you are using the Scrum framework or another similar iteration based approach.
Within the actual sprint the sprint review happens on the last day of a sprint or the first day of a new sprint.
I usually try to do sprint reviews before retrospective and sprint planning.
This order allows your team to discuss any product feedback from the review at the retrospective. It also allows the team to incorporate any revisions during sprint planning.
Why Do Sprint Reviews
You primarily do sprint reviews to get product feedback from your stakeholders when you can’t get feedback from them during the course of a sprint. Sprint reviews also give you an opportunity to reflect on progress toward your target outcome and make adjustments.
The sprint review is structured as an explicit discussion to look at progress, get feedback, and make revisions. Ideally though, you should have those discussions on an ongoing basis and not rely on sprint reviews as the only mechanism to get feedback.
How to Lead a Sprint Review
Identify who should attend the sprint review.
It’s good for the entire team to attend. It’s helpful for the entire team to hear the feedback they are getting from stakeholders (customers) so that they get a better understanding of what stakeholders are looking for. They may also pick up on something that other team members don’t.
It’s also helpful to consider which stakeholders have an interest in the backlog items the team is working on during the sprint. This is a good discussion to have during sprint planning so that you can specifically invite the people who have a vested interest in the backlog items the team will work on during the sprint.
If you are working on a software product, identify customers that you would like to include in your sprint review. You may not include customers in all of your demos, as you may not have something to show meaningful to your customers (hopefully that doesn’t mean you didn’t work on anything that delivered value.)
Taking this approach instead of creating a blanket invite to hundreds of people who may possibly be interested in what you are doing some time helps you have more engaged attendees at your sprint review, and is more respectful of everyone’s time and calendars.
Remember whomever you invite, don’t make it hard for them to give feedback.
Identify who should facilitate the sprint review
It depends what you are trying to accomplish (beyond receiving feedback that is) and the makeup of your team.
I’ve seen the developers demo their own backlog item. This is good if you’d like to get some recognition for the developers and they won’t go off the rails and give a 30 minute discourse on the nasty details of how they completed the story.
I’ve seen analysts or testers facilitate sprint review. This is usually the case when they have a strong relationship with the stakeholders and the team feels that they can best convey what the team accomplished.
I’ve seen product owners facilitate sprint reviews, for the same reason as why analysts or testers would facilitate a sprint review. Just make sure you as product owner aren’t doing the sprint review because you don’t trust the team to do it properly. This is a sign of a dysfunctional relationship with your team.
I’ve seen members of the business unit who are working closely with the team facilitate the sprint review. This is often a way of subtle organizational change management. If other members of a team see someone from their team using the new solution, they likely conclude that it must not be that scary after all and is something they could use.
Perhaps the stakeholders (customers) should play a major part of the sprint review themselves by actually just playing around with the software. In fact, that may be the most effective way of getting meaningful feedback, and certainly something to consider if your solution is in a state that people can start using.
Have a clear agenda
Whether you prefer to use a brief presentation to guide the discussion in your sprint review, or make it a bit more informal, you should at least have a specific agenda of what you want to talk about.
Here’s the minimum agenda I’d suggest for sprint reviews to make sure you’re satisfying the goal of reviewing progress, getting feedback, and discussing revisions.
- Remind everyone of the desired outcome and your sprint goal.
- Summarize the backlog items the team completed in the sprint and anything you learned during the sprint.
- Demonstrate completed work. Note that you may want to follow these demonstrations up with the opportunity for your stakeholders, users, and customers to try out the functionality for themselves (usually after the review)
- Ask the attendees for their feedback on the work that you demonstrated and results the team discussed with respect to achieving the desired outcome.
- Discuss any potential adjustments you may need to make to your plans based on what you’re trying to accomplish and the progress you’ve made. Depending on how frequently you deploy changes to your product, part of the discussion may be whether there is enough to deploy.
Caveats and Considerations
The sprint review is for stakeholders, not the product owner.
Sprint Reviews shouldn’t be the only way to provide feedback to your team.
If you are truly doing your job as a product owner you are providing feedback along the way so that your team has a shorter feedback cycle and has an opportunity to act on the feedback you provide within that sprint.
If you (as a product owner) are surprised during a sprint review, something is wrong.
Should we always do sprint reviews?
If you as a product owner have already had an opportunity to provide feedback to the team during the course of the sprint, and you were able to get feedback from the key stakeholders interested in what the team was working on, you probably don’t need a demo. You already have the feedback, so now you may just be doing the demo because that’s what teams do at the end of sprints. Unless of course you are using a flow approach, in which case you better be getting feedback after every item is done.
What if we don’t have stakeholder (customer) visible stuff, do we still do a sprint review?
Some teams (teams working in a mainframe environment or teams with a LARGE, complex code base come to mind) may find themselves working on stuff that provides value to stakeholders or customers, but is not very demonstrable. If you find yourself in that boat, think through what would be a good way to get feedback on the work you did. Mainframe teams I worked with used before and after screen shots. Admittedly not very sexy, but it was sufficient to get the point across and to generate conversation and encourage feedback.
Remote Sprint Reviews
For remote sprint reviews, we use Zoom because there are people included who are outside of the team involved. We’ll put together a few slides providing an overview of where the project is, mainly due to a request from the organization we’re working for right now.
After sharing a few key pieces of information I’ll demo any new user facing functionality the team produced. Then we’ll open things up for discussion.