The most discernible activity during a sprint review is a demonstration of the functionality built during the sprint. But, a good sprint review includes more than just a demo.
Watch the video or read on for an example sprint review agenda that works for me.
Welcome Participants & Set the Stage for the Sprint Review
The product owner starts by welcoming everyone to the sprint review. This can be as simple as saying, “Thank you for being here.”
If participants are unfamiliar with one another, the product owner may have attendees briefly introduce themselves. Introductions are generally a good idea at the start of a new product development initiative. The product owner knows that Joe from Marketing is Joe from Marketing but team members may not.
Introductions are also helpful if it is common for an occasional new participant to attend sprint reviews. Perhaps Joe from Marketing will only attend two reviews following the sprints in which the team worked on marketing-related features.
Introductions should be kept extremely short. “Hi, I’m Mike and I’m a developer. I’ve been working on the shopping cart features,” is plenty. In some cases, “I’m Mike and I’m a developer,” would be enough. But once a team reaches a certain size, it can be helpful for stakeholders to hear a few words to let them know who has been doing what.
After an initial welcome by the product owner and any needed introductions, the product owner can share any ground rules or expectations for the sprint review. For example, some product owners find it necessary to state the need to keep the meeting civil. If someone doesn’t like how a feature was implemented it’s fine to say so, but don’t call the implementation “stupid” or so on. Yes, we all should know things like this anyway, but sometimes people need to be reminded.
Depending on the number of attendees and many other factors, a product owner might also state that while she is looking for feedback on what was built, the sprint review itself will not be the time to redesign features.
With the welcome message, introductions, and ground rules out of the way, it’s time to move onto the next item on the agenda.
State What Will (and Will Not) Be Demonstrated
At this point, many teams dive right in and start demonstrating. Instead, I recommend the product owner present a very brief overview of what will be demonstrated and what will not be.
To avoid a product owner just reading a list of items that participants won’t be able to follow, display something on the monitor or projector being used. Or have printed copies available for those who want one.
I like to prepare this as a document and email it to likely review participants at the end of the day before the review. This allows people a chance to see what will be demonstrated. Each person can then intelligently decide whether to attend or not based on what will be shown.
The following table shows the information I like to include for each product backlog item. I recommend putting this list in the order in which items will be demonstrated, although you can change that on the fly as needed during the meeting.
| Description | SIZE | STATUS | DEMO |
|---|---|---|---|
| As a user, I .... | 5 | Finished |
Yes |
| As a user, I .... | 3 |
Finished but there’s more we could add to the such-and-such part of this. |
Yes |
| As a user, I .... | 5 | We started but there were too many open issues | No |
| Bug fix: Update the copyright notice on the About screen | 0 | Finished | No |
| ADDED: As a … | 3 | We brought this item in when we dropped the item above. | Yes |
The table starts with a description of the item. Put the user story or other description here. Next include the size of the item, usually this will be in story points. Then list the status of the item. Mostly this is whether the item was finished or not, but include anything else that is important to note. Finally, include a column indicating whether the item will be demonstrated or not.
You may wonder why we’d ever have items that the team would not demonstrate during the sprint review. I’ve provided a couple of examples in the sample table.
The item that was planned into the sprint but dropped typically wouldn't be demonstrated (unless the team completed enough to get feedback that helps solve open issues). I’ve also shown a simple bug fix that updates one character on one screen—it is not scheduled for demonstration either. And that's OK. It's doubtful that a bug fix needs any feedback from stakeholders. Sometimes showing too many small details can frustrate stakeholders and cause problems with sprint review attendance.
It’s quite possible that one or more participants might ask to see an item that you had not planned to show. When that happens, go ahead and demonstrate the item along with all others. You’re not trying to avoid showing something, you’re just trying to engage stakeholders in sprint reviews by being respectful of people’s time by not showing them things that don’t really need feedback.
Notice in the sample above, I indicated that one product backlog item was added to the sprint backlog during the sprint. I think it’s a good idea to indicate items added during the sprint so they can be distinguished from those that were brought into the sprint during sprint planning. If adding items happens frequently, consider adding an initial column and putting P (for Planned) or A (for Added) in it.
You might also want to consider a column at the far right that can be used to indicate whether each item is accepted by the review participants or ready to release or such. Do this if those types of decisions are formally made as part of a sprint review (Here's why I don't recommend using the sprint review as a sign-off meeting).
Avoid spending too much time on this part of the agenda. The goal here is not to get feedback on the items or to talk about why a planned item was only partially implemented. This is merely a table of contents into the rest of the meeting. After the product owner has presented this list, move onto the main part of the sprint review: the demo itself.
Demo New Functionality
This is the heart of the sprint review. And if you’re already doing sprint reviews, it’s quite possible this is the only part of the agenda you’re doing.
During this portion of the review, proceed down the list of items you’ve previously shown meeting participants. Keep in mind that the purpose of the sprint review is to solicit feedback.
There is no hard rule about who gives the demo. In some cases, a product owner will operate the keyboard. I’d recommend doing that in a review with particularly challenging stakeholders. Other times, though, team members will demonstrate the specific product backlog items they worked on. Just about any approach works fine. So experiment to find the one that works best for your team.
Discuss Key Occurrences
After all completed product backlog items have been demonstrated, discuss key events or problems that occurred during the sprint.
This discussion could be facilitated by either the product owner or Scrum Master. I’ve found both approaches to work equally well. I do, however, have a slight bias toward having the Scrum Master conduct this part of the meeting.
Up until now, in most sprint reviews the product owner will have done a lot more talking than the Scrum Master. So I find it a good balance to have the Scrum Master facilitate this agenda item. Plus, this is often more a discussion of the process than strictly the product, and so it falls a bit more in the domain of the Scrum Master.
Present Upcoming Product Backlog Items
The final item on a sprint review agenda should be a discussion of the next work on the product backlog. Because the purpose of the sprint review is to acquire feedback on the work of the current sprint, this will often influence what will be worked on in subsequent sprints.
If, for example, participants in the review liked the look of the new screens, the product owner may want to accelerate moving other parts of the product to the new design. Or, if participants didn’t like how a feature was implemented, perhaps the next sprint should be spent fixing issues with it instead of moving onto the next items, as might have happened without a sprint review.
The product owner starts this discussion by presenting the next set of potential items from the product backlog. The product owner might say something like, “On the screen, you’ll see what I thought would be our next ten things to work on, but I want to insert such-and-such that came up today. I’ll add that probably as item three.”
The product owner then solicits comments from participants about the proposed next set of items. I do not, however, recommend that the product owner make any prioritization decisions during the sprint review based on these comments. The reasons for this are many. The product owner may need time to think about what was said in the review. Or the product owner may want to get estimates from the team about changes that were requested in the review. And so on. Instead, the product owner solicits opinions during the sprint review and then makes decisions after the meeting.
Conclude the Meeting
Simply wrap up by thanking everyone for participating. Consider thanking the team in whole for the work of the sprint. Consider occasionally praising a team member or two who performed exceptionally well during the sprint. Remind everyone when and where the next review will be held.
After the Sprint Review
Although not part of the agenda for the actual review, someone should enter any new product backlog items into whatever tool the team is using (or post them on the wall if using physical cards).
How Do You Conduct Reviews?
Please let me know how you do your sprint reviews. Do you include anything in your sprint demo agenda I didn’t mention? Do you skip some of these steps? Please share your thoughts in the comments below.
