Do you know what happens at a Sprint Review Meeting?
This is the meeting where the Product Owner accepts or rejects the stories in the Sprint and the Sprint itself.
The Team, having prepared for the meeting, presents the stories to the Product Owner.
One person, often the Scrum Master, presents a summary to the Product Owner of the stories committed at the Sprint Planning meeting and the stories being presented for acceptance. The Team seeks to have more stories accepted than originally committed. It is important that the Product Owner knows at the beginning whether The Team believe that they have over or under achieved the Sprint Goal.
Each story is then presented by the Team for acceptance. They aim to get the Story accepted as quickly as possible while being totally transparent, which includes declaring whether there are any known outstanding bugs (which should already be on the Product Backlog) and adherence to the Team's Definition of Done.
Note: if there are additional stakholders, make sure they are also in the loop and up to speed on the current increment.
If a Story is accepted, but more work needs to be done, a new Story to cover this work is added to the Product Backlog. Similarly, if a bug is found during the review, it is added to the Product Backlog.
If a Story is rejected and returned to the Product Backlog but the Sprint itself is accepted, then a careful decision needs to be made. If changes have been checked-in to the Sprint's branch then it must be established that these changes have no adverse effect or they must be carefully undone before the branch is merged with the trunk. For this reason, it is always safer to accept stories with conditions rather than reject them.
The Scrum Master keeps the meeting on track and to the Timebox by disallowing discussions not relevant to the acceptance or rejection of the story; this is often done by making a note to bring the subject up again in the Retrospective Meeting.
This meeting is normally time boxed to as many hours as there are weeks in the Sprint.