A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
So the Sprint Review should be a informal, collaborative working session. Lot's of interaction with the stakeholders is sought for, not the passive acceptance of whatever drizzles down from the stage.
A good Sprint Review could have the following format:
- The Product Owner welcomes all attendees (especially the stakeholders) and reminds everybody of the product vision and the value he is trying to achieve (he shows the "big picture")
- Then, the PO shows the release target and the Sprint goal. He also states if the goal was reached or not, maybe even giving a reason in the latter case.
- The the Product Owner passes the ball over to the Development Team. They show very briefly what they have accomplished. They do not show anything that isn't completely "Done".
- After the short "demo" element, the true fun starts: The stakeholders get to try the product increment. They use it, touch it, feel it. Only then they notice if what they are holding in their hands (or clicking with their mouse) is what they actually wanted. The developers walk around and give a hand whenever needed. When new requirements are identified or changes to the Product Backlog are seen as necessary, the Product Owner records these.
- Together, the Product Owner and stakeholders examine the Product Backlog and the impact of what they have just seen. If deemed valuable, the Product Owner adapts the Product Backlog
- The Product Owner thanks everybody for their input and closes the meeting
This flow is not prescribed by Scrum. However, I personally find it very useful.
You might still ask yourself when the work of the Development Team is formally accepted. Well, the Sprint Review is the last possible moment for this, not the only one. And it is a bad point in time to do it. After all, the stakeholders are present in the meeting - if the Product Owner is surprised by his Team's results, he is standing on the stage with his pants dropped. No chance at all to gather more information or rectify a mistake. So instead of accepting this huge risk, good Product Owners will accept or reject the team's results during the Sprint. Usually, Product Backlog Item by Product Backlog Item and on the day when the Team claims they are "Done". The PO works with the team on a daily basis, so this shouldn't pose a problem.
Scrum does not define when the stakeholders formally accept the results of the Product Owner (he is the "single wringable neck", so he is on the line for his stakeholders), so it can be defined by each product/project. It can be done during the Sprint Review, but this usually diminishes the quality of the meeting because everybody is trying to look good instead of collaborating on what has to be done next. Smart Product Owners will try to detach formal acceptance from meetings and connect it to KPIs instead, e.g. the primary value KPI. If the primary reason why this project is conducted is a sales number (e.g. 1 million), then actually count sales. Who cares if the initial plan or certain "gates" are achieved when sales skyrocket?
