To make Scrum processes effective, simply dividing the development cycle into short iterations is not enough. It’s critical to share the value of all aspects of Scrum and strive to make each iteration better than the previous one.

Sprint Review can be a great tool to achieve this goal: by presenting the product increment as the result of the sprint, the team receives feedback from the stakeholders to estimate the scope of work done and clarify which product elements are good, and which ones should be improved.

However, as with every Scrum tool, 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.


Sprint Review: Description and Main Objectives

Sprint Review is one of the Scrum events held at the end of a Sprint.

Its objective is to inspect the increment, the total product that the team has managed to produce in all previous sprints, and check its readiness for a potential release.

Review is conducted before the Retrospective. Both stages are interconnected with each other with a common objective ─ identifying strengths and weaknesses. Still, if the Retro is about analyzing the team's work process, then the Review is about analyzing growth and changes in product functionality.

During Review, the team and stakeholders analyze the product backlog that was included in the last sprint. Additionally, the team may demonstrate the user story and new product features for everyone interested in its success.

Another important objective of this event is to get feedback from all stakeholders. To do this, The Scrum Master organizes the meeting with the product team, engineering team, and all interested persons such as potential users, etc.

The main stages of the Review Meeting are described in the infographic below:


Sprint Review Meeting

Bad Sprint Review: Common Mistakes

To make this Scrum Event not ‘just a meeting’, but a productive exchange of valuable information, 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, 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 over the course of several Reviews, the product backlog doesn't change, then they were incorrect or even nonexistent.


The List of the Invited Participants is Not Optimal

A good Sprint Review Meeting only includes attendees who are directly related to the product and influence the development process.

The bad Sprint Review Meeting may include additional participants, some of whom are outside the development context and the product itself.

As a result, instead of sharing feedback, participants engage in non-constructive conversations and, again, waste each other's time.


Good Sprint Review: Success Criteria

The above cases are unacceptable when organizing and holding the Review, but it is not enough just to avoid these mistakes and call it good.

Let's identify the important points that contribute valuable results to the event.

At the start:

  1. Product increment availability.
    The sprint should have an outcome that the team will demonstrate as a result of their work. In a good Review, the team presents the increment and stakeholders and users give feedback on it. The best way to show the actual amount of work is to visually demonstrate how the increment works.
  2. Understanding the Sprint goals.
    The goal is a general guideline for the team that keeps the focus on the entire product development, rather than on individual features and user stories. In a good Review, the Sprint goal is set by the team during planning to evaluate whether the team succeeded in achieving this goal or not.
  3. Prepared Sprint backlog.
    To evaluate a sprint, you need to have a list of user stories that the team has committed to deliver. At the end of the sprint, this list will help determine the productivity of the team and processes in general.
  4. Collected metrics.
    The quantitative indicators of the team's work allow you to objectively assess its effectiveness. The main metrics include:

If the Review is carried out correctly, then at the end of the meeting you will have:

  • systematized stakeholder feedback.
    All Stakeholder feedback is handled by the product owner and entered into the backlog as new, prioritized user stories.
  • updated product backlog.
    Based on the feedback and focused on business goals, the backlog is updated to adapt the product to the changing market and user expectations.

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

As with all Scrum Events, Sprint Review's primary goal is to improve processes, team interactions, and the product itself.

During Sprint Review, the team demonstrates the product’s progress, collects feedback and determines further actions to make the product better.
When conducting Sprint Reviews, we at Techstack follow the main rules to make them effective: demonstrate the increment in accordance with the requirements, collect feedback from stakeholders to move them to backlog as new, prioritized user stories, and, if necessary, update the product development 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 operation of your processes and improve your product.