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 read on and discover how to correctly perform a Sprint Review.

Let’s go back to the basics. 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.

Okay, now that we’ve covered that part it’s time to learn how it’s 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: 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: 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: 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.

—-

Need help with the agile methodology? Send us a message and our experienced agile coaches will guide you towards a more streamlined, productive workflow.