sprint review

What is the Sprint Review That we Often Skip?

If you are going agile, you probably have decided to go by the book (as you should) and implement the process of the four major meetings that take part within a sprint. You have started with the planning of what would you like to achieve and how will you do it, you are attending the daily scrums to catch up with the development team and now your sprint has come to an end. As mentioned to the Scrum Guide, this is the time to go back, inspect the increment and adapt accordingly the Product Backlog if needed.

We have already done this”, “we are too busy finishing the Sprint” and “this is unnecessary, we only do it because we have to” are some of the typical reactions teams have against the Sprint Review Meeting. You either are or will be part of a similar situation where your team will struggle to see the real value of it and decide to skip it or combine it with the Retrospective that comes next.  

Why you Shouldn’t Skip the Sprint Review

You firstly have to understand its purpose and importance. If you are a user of Jira, the dragging of a task from Review to Done is definitely your ultimate satisfaction, but this meeting is not about listing whatever has been completed and this is not where your focus should be. The Sprint Review is an opportunity for the Scrum Team to align with the stakeholders, the ones that they don’t meet with or speak daily. Furthermore, it is intended to gather feedback and foster collaboration between the two sides on what to do next, ‘fueling’ the input to the Sprint Planning meeting that will follow. Having listened to all the stakeholders involved, the result will be a revised Product Backlog adjusted to meet new opportunities.

Who Needs to Attend in the Sprint Review

Whilst it’s the Scrum Master’s responsibility to ensure that the event takes place and the attendees recognize the meeting’s purpose, it’s up to the Product Owner to invite the Stakeholders and the entire Scrum Team. Their attendance is vital, as the acquired feedback will in return help the Product Owner tailor the Backlog to fulfil everyone’s expectations. It will be the moment to bring their interests into representation and develop transparency, as without it, predictability will not be optimised and risks won’t be controlled.

How Long Does a Sprint Review Last

Similarly to the rest of Scrum events, the Sprint Review is a time-boxed meeting of a suggested two hours review for a two-week Sprint. As a rule of thumb, this is adjusted to an hour per week of Sprint for a casual meeting.

Always Gather Sprint Review Feedback

See it as a feedback party. The Product Owner will be the party organizer and the Scrum Master the support to the event. Yes, the attendees of the Product Team will need to demonstrate the results, but will this be just a one-sided presentation? You want to gather everyone’s feedback and keep them engaged to the topic, so make sure your party vibes foster collaboration and promote the so wanted in-depth feedback. Last but not least, be proactive and check the guests list ahead of the event, so you prepare its content accordingly. Repeat attendees will consider the recap of the previous Sprint a time-consuming process. On the opposite, first joiners will value an informative briefing on the latest updates. Finding the right balance between the two will be a challenge, but aren’t all the parties like this?

A Successful Party

Kick-start the party with your Product Owner to attract everyone’s attention. Going briefly through the vision, product roadmap and the deliverables within the latest sprint, basics will be covered and the teams can get dismissed. Attendees will then be invited to explore the teams that they wish to contact in a more direct way, giving them the chance to go through the increment with them in depth. This is the time to ask your Scrum Master to put some magic and coach the team.

Yes, the PO will be your main host, but the rest of the members will need to act as such too. They need to be engaged to the process and actively pulling in your stakeholders. Starting by inviting them into the real ‘feedback party’, they can be walked through the deliverables around the product, interact and share their opinion on the matter. The team can then thank them for their contribution and allow them to move on. Such a technique sees great results especially when various teams are involved into a sprint. Last but not least, have in mind that such a party will give your stakeholders the option to pick and choose the time they want to spend in the areas they want to learn more without having to hear all over the story again.

The Dysfunction Scenario

In complex environments, feasibility along with quality and speed of delivery cannot be predicted with accuracy.  Grasping the Scrum’s fundamentals doesn’t always mean that everything will work perfectly for you and your team if you follow the plan. Let me share my thoughts…

What if you don’t meet the Sprint Goal? Is that a big deal? Well, yes since you won’t be in the position to present a complete increment. Furthermore, a debate arises: will you extend the sprint or delay the Review? Here is where Scrum’s values come into play again and it’s all about continuous improvement. No blame, excuses or phrases like “the commitment wasn’t met” are to be heard. On the contrary, openness must be rewarded and all parties involved need to respect the Product Owner’s authority. Stakeholders’ interests might be incompatible to what the Product team is able to deliver and the Product Owner will probably end up taking hard decisions that won’t be satisfying to all, but that’s all the Review is for; taking into account their feedback and adapting the Backlog for the next Sprint.

*Tip: If you recognize in your organisation the challenge between Product Ownership and Stakeholders’ representation, try playing Stakeholder Tycoon.. A fun game to give everyone a better understanding of the interrogations that a PO has to deal with.


In a nutshell, it’s all about showing that you got things done. No endless talking and mockups would show your work. It’s the time to get excited and show off your product, develop transparency and build trust with your stakeholders.

Do you really wanna skip this? We guessed right, so let’s get your party started.

Frequently asked questions

What is the purpose of sprint review?

The purpose of sprint review is to assess the completion of all the tasks that the team planned to complete during the end of current Sprint. This is an informal meeting that everyone is free to attend: team members, Scrum Master, Product Owner and business owner. The goal of the meeting is to elicit collaboration and feedback from all involved parties while providing business context for the product and future tasks.

How do I do a sprint review?

To do a sprint review you need to gather Scrum team members, business stakeholders, and other interested parties so that team members could demonstrate to everyone the working increments of a product they completed during the Sprint. Freely allow visitors to engage in collaborative discussion, but make sure that every team member is able to demonstrate results of their work within the meeting;s timeframe.

What is the difference between a sprint review and a sprint retrospective?

Sprint review is largely an informal meeting used for facilitating collaboration between team members and business stakeholders. Sprint retrospective is a Scrum ceremony meeting with a clearly defined purpose of unveiling ways of improving team performance. Sprint review meetings don’t have clearly defined outcomes, while Sprint Retrospective urges the team to compile a list of actions they need to implement to make the next Sprint more effective.

Leave a Reply

Your email address will not be published. Required fields are marked *