How to do a Sprint Review in Agile Development

If you’re on a team just starting to get into agile development, or on a team who have long been applying it but suspect you may be doing it wrong, then you will want to know how to correctly perform a Sprint Review.

A sprint review is a meeting held after a sprint (typically lasting 2 – 3 weeks) has been completed. In this meeting, the team demonstrates a working product to the Product Owner and everyone else who is interested (stakeholders). After the demonstration, the Product Owner reviews which items are actually “done” (if they work, meet accepted criteria, and have been fully tested) and those items which are not done are added to the Product Backlog to be later prioritized by none other than the Product Owner. These items would then be candidates for future sprints.

Why is this meeting necessary? Well, it’s an effective way to iteratively refine everyone’s understanding of the projects’ requirements, get everyone on the same page concerning its progress, and allow the client/stakeholders to realize what they really want, which is much easier for them once they see actual functioning software.

So how is it done? There are 4 steps you can follow to make sure you cover all bases. Do keep in mind that the most important deliverable from a sprint review, is a modified Product Backlog. On with the steps.


Step 1: Present the demo of your working product

This can be done by the Scrum Master or by one or more team members, preferably one who knows the product well enough to prevent showing uncertainty about their work in front of the stakeholders. Also, avoid showing anything that isn’t completely functional. It’s not a good impression when the presenter tries to show off the project and all you hear is the team saying “Oh no don’t show that yet!”.

Step 2: Discuss changes to the product with the team 

The development team discusses what they consider needs to change or improve for them to complete a backlog item (ex. Poor code that needs refactoring). These considerations are put into the Parking Lot unless they strongly impact the product, in which case they would go into the Product Backlog. It’s important for those involved to hold off any questions or discussions they may have until the very end of the review, this is to avoid distractions and going off on a tangent.

Step 3: Product owner aligns expectations with the stakeholders

The Product Owner reviews with the stakeholders and announces any changes made the project (timeframe, tasks, priorities, etc.). These changes are put into either the Parking Lot or the Product Backlog, depending on their importance to the product and to the stakeholders.

Step 4: Product owner prioritizes the tasks in the Product Backlog

Now it’s time for the Product Owner to prioritize the Product Backlog and move any less important items to the Parking Lot. Here it’s important to focus solely on the product and avoid prioritizing items that only affect the team. If there are items that the team consider to be of vital importance, then make sure to ask them exactly why it should be high priority, don’t just take their word for it.

Once your sprint review is done, it would be wise to make note of all the feedback and make it visible to both the team and the stakeholders, just to make sure everyone is on the same page and that the feedback collected is accurate.


So now that you know how to conduct an effective sprint review, how about you learn how to perform a sprint retrospective by reading this post!


Was this post useful? Follow us on Facebook and Twitter for tips and tricks, news, and a peek behind-the-scenes of Balystic.

Leave a Reply