The sprint review – why is it important and what are best practices

The sprint review is part of every sprint cycle. It is a standing meeting at the end of the sprint in which the team presents the developments to each other, to the Product Owner (PO), hopefully also to the key stakeholders, and sometimes to actual users or customers. 

To me, the sprint review is an extremely valuable ceremony. The principles behind the session itself are powerful and applicable outside of Scrum as well. Nevertheless, I feel that the goal and the importance of the review is sometimes misunderstood.

Thus, I want to dive into the ceremony. I will explain why reviews are conducted in the first place and share some best practices that I have found beneficial in making the review that more valuable.

Email address:

Leave this field empty if you're human:

What are the goals of the sprint review?

The review serves various purposes. In my view, three goals stand out. One is the explicit goal of the review and (mostly) well known. The other two are less prominent, but extremely important side effects of having an effective review. For me, the three most important reasons for having a review are: 

• Feedback on completed developments
• Motivation and team building
• Canary in the coal mine

Feedback on completed developments

First and foremost, the sprint review is the place to gather feedback on completed product increments. The goal is to show to key stakeholders or users what was developed and elicit a conversation. 

This conversation will initially be focused on the past sprint. It should, however, also dive into what is to come next. Thus, the review can also be the place where important decisions on the next steps are taken. 

Within the review, stakeholders are encouraged to give feedback. If they choose to, they are also able to dive into the solutions, understand the technical background, and the difficulties in implementing the jointly written user stories. This way, the team also gives feedback on the requirements and stakeholders gain an understanding as to what is technically possible.

This discussion is extremely valuable. It creates a shared understanding of user needs and requirements as well as of the technical solution space. Especially in an uncertain environment, the feedback is the input to jointly determine how to proceed.  

Motivation and team building

Now to the less obvious reasons for why a sprint review exists. It is a platform for the team members to showcase themselves and their work. As such, an effective review is a great tool for team building and a source of motivation.

The review is the place to celebrate the team’s achievement within the last sprint. This celebration creates a real sense of ownership.

I have found that even the most quiet and shy developers smile when they are able to show what they did. You can sense a feeling of pride when able to explain the problems they faced and how they solved them. This builds motivation, especially when the stakeholders – sometimes senior management – truly show their appreciation for what was done. 

Canary in the coal mine

Last but not least the sprint review serves as a canary in the coal mine for the team. It is an early warning system. The sprint review should inherently be something that is extremely positive. If the participants are consistently unhappy after the review, this means something is off. 

The reasons can be many. In case the stakeholders are unhappy, the team might be working on the wrong things, the PO could be lacking communication skills, or the refinement process might not be as effective as it should be. 

If the team is constantly unable to complete the sprint, stories might not be sliced correctly, stakeholders might be meddling with the sprint, or it could be a sign that the quality of our product is insufficient.

Whatever the reason may be, it is extremely important to monitor how the reviews are going. If they are consistently negative, something needs to change. We need to then dig and understand the root cause.

In this context, I want to stress that a single “bad” review can happen and doesn´t necessarily mean anything. The above is about consistently having a negative review experience.

Sprint review – my best practices

Now that we have established why the review is necessary, I will dive into some best practices that, in my experience, ensure the scrum ceremony is effective. Honestly speaking, the sprint review is not terribly complicated. Nevertheless, I feel it makes sense to expand on three points:

• Roles & participants
• Taking your time
• Story acceptance

Roles & participants 

The review is open for anyone to attend. Technically, only the team itself needs to be present during the meeting. However, since the ceremony is aimed at getting feedback on what was done, the PO should at the very least invite key stakeholders. If possible, actual customers or users join. 

If stakeholders and/or users cannot join the review, e.g. because all development teams have the ceremony in parallel, the PO must take their point of view. In this case it can make sense to set up a separate demo meeting. This way, the team has an internal review where they can go extremely deep into the technical topics (and maybe feel more comfortable to speak openly) while still having a platform where to get feedback from key stakeholders.

This is how we currently do it. All the development teams have internal reviews with their respective POs first. Later on, we have a demo where all teams present one or two items to the entire company.

Speaking of presenting, the developers are the one to show what was done. Of course, the Scrum Master can facilitate and the Product Owner can give some background information. However, the review is there to celebrate the team’s achievements. The person that implemented the solution is the one to show it.

Preparation should be kept to a minimum, however. We want to show real results, ideally in the live systems. There is no need to create fancy presentations.

Taking your time

As mentioned above, one goal of the review is to showcase what the team did. In my experience this is not easy in a rushed setting. Thus, I highly recommend taking enough time to discuss everything.

We currently have two week sprints. We spend at least an hour, often times close to two, to go through everything. This gives us time to really understand what we did.

Knowing that we are in no need to rush means I always have time to explain why each and every story task was done, how they fit into the bigger picture. I have the feeling that this is extremely important for team motivation. It shows the value of every small thing we completed.

Story acceptance

Some understand the sprint review to be the one time during the sprint where stories are accepted and moved to done. This is not how it should be. Every once in a while, I see teams operating in such a way and thus want to stress here that story acceptance is something that should happen continuously during the sprint.

It’s fine if a few stories that were completed at the last minute are accepted and moved to done in the review. The vast majority of stories should be accepted upfront. This is one of the key jobs a PO has.

The goal of agile development is creating value as fast as possible and then getting feedback from users. Completing the development of a feature but then waiting a week until the review is slated to happen before it can be deployed is completely contrary to that idea.  

What if there is nothing to show in the review?

Something worth mentioning, it can happen that teams consistently have nothing to present. Several factors can cause this and it could be a major red flag. Stories are not broken down enough or sliced correctly, teams are not set-up correctly (i.e. no end to end responsibility), or the Scrum process needs to be adapted to better fit your circumstances.

If a team consistently has nothing to show it is an indication that agile product development is misunderstood, wrongly implemented, or doesn´t fit the environment. Often, this situation can only be remedied with management or outside support.  

Conduct regular reviews outside of Scrum

I would argue that the principles behind the review are universally desirable. Thus, I also encourage leaders of more traditional development teams to think about implementing something similar to the Scrum review. It doesn’t have to be anything special.

Simply create a platform, where the developers are able to show what they did, make sure that everybody knows why it was done, let the stakeholders give feedback, and ensure you have enough time available to discuss all questions that come up. Use this discussion as input for planning what is to come next. That’s it. 

If you then add some honest praise as the cherry on top (if it is warranted) you might just end up with a high performing and motivated team with or without using the term Scrum or agile.

Coverphoto by Markus Winkler on Unsplash