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 believes that they have over or underachieved the Sprint Goal.

Each story is then presented by the Team for acceptance. They aim to get the Story accepted as quickly as possible (aka tick and flick) 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.

Video: Explaining a PBI to a Product Owner with Jake Bayliss (5 min)

Note: If there are additional stakeholders, 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.

It's important that stakeholders stay in the loop of the projects progress, but they are often too busy to join the Sprint Reviews. Before the summary, you should try loop them in and if they cannot join, record the summmary and send a link.

What if you can't attend the Sprint Review

If you can't attend your team's Sprint Review (e.g. you're on leave, working part-time, or in a different timezone), you should give the team a summary of where you're at, so they can inform the stakeholders on your behalf.

• Send a brief "Sprint Review" email to the team to provide them with an update on the status of your tasks. This will enable the team to pass on the information to the client.