In Scrum, each Sprint ends with a Sprint Review. A good Sprint Review is much more than a demo, but the demo is all that some teams do - in fact many teams label this event as the ‘Sprint Demo’, unfortunately reinforcing that misperception.

The Sprint Review has two goals:

1. Get actionable feedback from stakeholders & customers on the delivered product — early and often — to inform better product decisions.

2. Share progress metrics and set expectations with key stakeholders

Here are some things to try to accomplish these goals in your Sprint Reviews.

1. Invite the right people. Who can provide the feedback you need to help make better product decisions? Which stakeholders need to know about out KPIs and progress toward goals & milestones?

2. Remind your stakeholders about those two goals above, and and ask how we can best accomplish them.

3. Let your developers shine. The people who built and tested the product should be the people who demonstrate it to stakeholders. Bonus: this generates a greater sense of ownership when people know that they’ll be showing their work to customers.

4. Make it a test drive. Put stakeholders in the driver’s seat by having them use the product during the review, rather than passively viewing a demo.

5. Share KPIs that your stakeholders care about: quality, cycle time, customer engagement, etc. Even better, build a dashboard of these metrics that’s always visible.

6. Set stakeholder expectations. What is planned for the next Sprint? What is the latest product roadmap?

7. Don’t wait until the end of the Sprint to review all the work. The goal is to close that feedback as past as possible, so demonstrate features/stories as soon as they’re completed. (This is standard practice in kanban.) At the Sprint Review, demonstrate any remaining features that stakeholders haven’t yet seen — in addition to sharing KPIs and setting expectations.