The Sprint Review For Product Owners

The sprint review takes place at the end of each sprint. It is designed to be a meeting in which the team demonstrates the functionality of the product produced during the cycle so that the Product Owner can inspect it and decide whether or not it is fit for purpose. It is a very informal meeting, and it should be seen as a natural end result of the work carried out during the sprint.

Sprint Review Participants

Everyone involved and interested in the increment of software that has been produced should attend the sprint review. This includes all members of the Scrum team, especially the Product Owner, and the Scrum Master, as well as all key stakeholders such as customers and managers. In some cases, it may also make sense for developers from other projects to attend, particularly if they are working on features that interface or integrate with the software that has been built.

Purpose of the Sprint Review

Each sprint should produce a potentially shippable product increment. In other words, at the end of the sprint, the features produced should have been not only developed but also tested and be fully usable. During the session, all attendees are encouraged to collaborate and give feedback on what has and hasn’t been delivered. The members of the Scrum team also answer any questions raised by the other stakeholders on the deliverables. The Product Owner’s role in this meeting is crucial, as it is their responsibility to ensure that the features meet all of the acceptance criteria and can be marked as done. It is the Product Owner who must make a final decision on whether to accept or reject each piece of functionality as being fully complete according to the specifications. Any stories that should have been delivered but were not completed are re-estimated and will be scheduled for delivery in an upcoming sprint.

Common Problems and How to Avoid Them

There are some pitfalls that tend to occur quite commonly during the sprint review. Below is a description of some of them along with suggestions that can help to mitigate these issues.

Product Owner Sees the Feature for the First Time at the Sprint Review

While the showcasing of the functionality that has been built is an important part of the sprint review, it should not be the first time that the Product Owner is seeing the feature in action. On the contrary, they should be working closely with the team throughout the cycle, and as a result would be well aware of the state of completion of the piece of work. This means that it should not come as a surprise if a story is rejected, as there would have been numerous discussions in the days leading up to the sprint review in which the team would have known about any acceptance criteria that would not be met in time.

Sprint Review is Treated as a Sprint Retrospective

If there are issues with some features, or some of the stories did not get completed in time, it is easy for the team to get drawn into a conversation about what went wrong during the sprint and what should have been done differently. However, these discussions, while important, should be dealt with at the retrospective so that the process of inspecting and reviewing the software isn’t interrupted. If necessary, the Scrum Master can make a note of any queries raised, and bring them up again later at the retrospective.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: