In Scrum, each sprint is required to deliver a potentially shippable product increment. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software.

As described in the Scrum Guide, a Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. There could have been a single Sprint Review deployment or many deployments during a Sprint which lead up to that Increment to be inspected. During this meeting, the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-box.

Stakeholder attendance could be a challenge for a Scrum Team. Key stakeholders might argue they don’t have time to attend each Sprint Review. They might ask for a status update or meeting notes to be mailed to them. It is indeed not essential for all stakeholders to participate or attend each Sprint Review. The Product Owner will invite key stakeholders relevant to the Sprint or the next.

Stakeholders will come to value this event as this is the most influential moment to get their interests represented.

At times a Scrum Team might argue not all its members would need to be present as it would do to just have a few individuals provide the demo or collect feedback. They clearly have not yet grasped Scrum’s fundamentals. It’s an opportunity for all inspect and adapt and to develop transparency. 

First and foremost, the Scrum Team processes feedback on the Product Increment. Not just from stakeholders, but also from its own team members. They collectively discuss these and align on it. The Product Backlog is revised to contain this feedback. Together everyone aligns on what to do and where to go next.

The Scrum Guide is already pretty specific as to what is supposed to happen during a Sprint Review and you could almost run through it like a checklist. So here it it directly quoted from the Scrum Guide with added emphasis.

-The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

-The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;

-The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;

-The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);

-The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

-Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,

-Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

During the sprint review, the project is assessed against the sprint goal determined during the sprint planning meeting. Ideally, the team has completed each product backlog item brought into the sprint, but it's more important that they achieve the overall goal of the sprint.

Do you have any questions? Ask us