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.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: