Why is the Sprint Review so important? Among all Scrum ceremonies, it's difficult to find any more tailored to delivered value than the Sprint Review. It contributes to constant iterative product growth and adds control and transparency along the development process. Scrum doesn't limit itself to dividing development into achievable parts; it also makes sure the team and the product improve with each iteration.
At first glance, you may think that Sprint Review is difficult to mess up, but that couldn’t be more incorrect. As with every Scrum tool, the Sprint Review should be used wisely. Here we explore what mistakes you should avoid and what tips you should follow to make Sprint Review productive for the team and the product.
Description and Main Objectives of Sprint Review
The Sprint Review ceremony is a Scrum team meeting where the Sprint results are demoed, reviewed, and discussed with the purpose of evaluating them and looking for improvements. The main objective of this meeting is to maximize the value delivered, find possible misconceptions and fix them before they can significantly affect the product.
Sprint Review isn’t the same thing as Sprint Retrospective. The Sprint Review meeting is conducted before the Retrospective, despite both stages being interconnected with each other with the common objective of identifying strengths and weaknesses. If the Retrospective is about analyzing the team's work process, then Review is about analyzing product growth and changes in functionality.
During the Sprint Review, the Scrum team makes a demo of the features from the backlog that they have delivered and features that they weren’t able to deliver for various reasons to different kinds of stakeholders. This enables the team to evaluate the current strategy and tactics of product development, discover pain points and possible remedies, and get stakeholder feedback.
The main stages of the Review Meeting are described in the infographic below:
Bad Sprint Review: Common Mistakes
To make Sprint Review productive, it’s important to conduct it correctly. Here are some common red flags that can appear during a Sprint Review.
The Sprint Review meeting has no time frame
Having an agenda with clear timing and a responsible person in charge of its implementation is an indicator of a good Sprint Review. And vice versa, If the meeting is timeless and unmonitored, then it becomes lengthy and useless discussions with the only one goal to create a sense of wasted time among the participants.
User Story doesn’t meet the necessary requirements
User story requirements are criteria that determine what exactly needs to be implemented to consider the user story ready for end-users. In a bad Sprint Review meeting, functionality that doesn’t meet the criteria can be shown as final and brought up to the necessary requirements only in the next sprint. Conducting the Review in this way is an unacceptable waste of time and resources.
Product Backlog doesn’t change after several reviews
One of the main indicators of team performance is the product backlog. Based on changes in the backlog, you can determine both the work productivity and the team involvement. If the product backlog has remained unchanged over the course of several Sprint Reviews, then productivity and involvement were low, and that needs improvement.
The list of the invited participants is not optimal
Pay attention to the attendee list of your Sprint Review. If you invite the wrong people who aren’t involved in the development process and aren't interested in the product you build, chances are that they will make the meeting less productive and suggest unnecessary improvements. The opposite is true as well; there’s no use to present the results to people who saw it in the process of work. That’s why you should invite all the stakeholders.
Good Sprint Review: Success Criteria
The above cases are common misleading practices when organizing and holding the Sprint Review; however, it is not enough just to avoid these mistakes and call it good. Below are the criteria that distinguish a good Sprint Review.
You have a product increment
It may seem obvious, but it’s difficult to make a review noteworthy when you have nothing to show. Make sure you have an increment in functionality to present and discuss.
Sprint goals are clear
Clear goals enable the team to be on the same page regarding the development of the whole product, not only a module or feature. The team sets a Sprint goal during planning; The Sprint Review is the perfect time to understand whether they reached expected results or not and why this has happened.
Backlog is set up beforehand
Prepare the backlog for a meeting: make it clear which user stories the team decided to build during the Sprint.
Metrics are collected
The quantitative indicators of the team's work allow you to objectively assess its effectiveness. The main metrics include the team’s velocity, Burndown Chart, Say: Do ratio, bugs reported per sprint, and many more.
Stakeholders provide feedback
All the enhancements and commentary that participants present during the review should be noted down as user stories and prioritized in the backlog so that the team can handle them in future sprints.
Backlog is updated afterward
In addition to new user stories that may be added during the Sprint Review, the priorities within the backlog should also be re-evaluated with the decisions being made based on the demo.
At the final stage of a good Review, the product and engineering teams have a clear understanding of the overall progress, points for improvement, and a common vision of how the product will develop further.
Conclusion
Sprint Review is a Scrum ceremony the primary goal of which is to improve the product and maximize the value it brings to the users. This meeting facilitates showcasing work results, getting feedback, monitoring progress, and correcting the product roadmap on the go, because wise changes make products successful. After this meeting, the Product Owner determines which further actions will make the product better.
We at Techstack follow the main rules to make Sprint Reviews effective: demonstrate the increment in accordance with the requirements, collect feedback from stakeholders to move them to backlog as new, prioritize user stories, and, if necessary, update the overall product vector to meet new market conditions and end-user needs.
Let's talk in more detail about Scrum processes! Contact us to learn the best practices our Development Consulting Team can implement to ensure the smooth processes that will make your product shine.