Product Owner’s Checklist for Sprint Review

The sprint review meeting marks the end of the sprint. It is the moment to demonstrate the work done and to provide feedback. The Product Owner’s role is to showcase the progress made by the scrum team on the product roadmap and be the ambassador of the product.

The goal of the sprint review meeting is to provide an accurate measure of progress, demonstrating the work done. The facilitator is the Scrum Master, and the schedule is:

1. Review the sprint goals
2. Demo and feedback on the work done.
3. Discuss the work not completed and the reasons
4. Identify risks
5. Give a sneak peek of the next sprint

Here is the checklist of the Product Owner for Sprint Review:

1. Review the sprint goal. Before all the participants come in, make sure you review the sprint goals and if you as the scrum team achieved them.
2. Work with the Scrum Master to agree on how to collect the feedback. If the participants are in the same room, you can distribute post-its and pens. Every participant will write one feedback per post-it and sign it. While feedback can stay anonymous, usually, people don’t have the time or the space to write everything on the post-its, So you might want to ask further questions after the meeting. If the participants participate remotely, I recommend you prepare a board with multiple sections, so the product owner or the scrum master doesn’t need to spend time sorting the feedback.
3. Distribute the materials/instructions for collecting the feedback before the meeting starts. Make sure you brief the participants on how to provide feedback.
4. Invite stakeholders, customers. Everyone interested in your product should participate in the sprint review.
5. Collaborate with the other Product Owners to do a joint demo of the work done. Some companies make it a company-wide event. Some of my clients make the Friday mornings the sprint reviews time, and all the teams demonstrate the work done. It is a very energizing moment.
6. Do a dry run of the demonstration of the “work done” — keep out those bugs and things that aren’t interesting for the stakeholders
7. Work on your confidence. As the Product Owner, you are the one presenting the demo — you need to be confident on the work done
8. Verify that the user stories meet the definition of done
9. Prepare all the data you need for the demo
10. Demonstrate the work done. You can demonstrate everything — spikes, nonfunctional requirements, user stories, reactors. It is essential to show the real measure of work done. Anyone from the team can do the demo.
11. Make sure the work demonstrated is on the acceptance environment, and not on someone’s laptop.
12. Discuss work not completed and why
13. Identify risks and impediments. I recommend you have a few risks in mind before the meeting.
14. Work with the scrum master to quickly log the identified risks during the sprint review
15. Review product backlog- give a sneak peek of what’s coming up next sprint without committing on behalf of the scrum team.
16. Evaluate the Program Increment objectives

Anti-patterns to avoid as a Product Owner:

• The sprint review is a demonstration from the team to you
• The demo runs on the local environment, instead of the higher environments
• The sprint review is a testing session of the work done
• Commit to the next sprint deliverables in front of all the stakeholders.
• Present a PowerPoint with the work done, instead of a live demo

You might be interested in:

Product Owner Checklist for the Sprint Planning

Product Owner’s Checklist for Product Backlog Refinement

How to involve your users in the Sprint Review?

How’s Like a Day in the Life of the Product Owner?

15 Things you can do as Product Owner Improve Team Velocity

15 Things you can do as Scrum Master to Improve the Scrum Team Velocity

Nine user story metrics I care about while coaching Scrum teams