In this article, we will talk about the Sprint Review event (ceremony) in Scrum. As we know from 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. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. So, let's talk about the Sprint Review meeting more detailed.
The Sprint Review is an informal meeting which the Development Team, the Scrum Master, the Product Owner and the stakeholders will attend. During the Sprint Review event, the product 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.
The timebox for the Sprint Review meeting is usually 4 (four) hours for one-month Sprint. For shorter Sprint, 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.
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.
The most discernible activity during a Sprint Review is a demonstration of the functionality built during the Sprint. But, a good Sprint review includes more than just a demo. Let’s take a look at an agenda for the review.
All Scrum Team members (Product Owner, ScrumMaster, and Development team) should be present at every Sprint Review so that they can describe what has been accomplished, answer questions, and enjoy the benefits of firsthand feedback.
Internal stakeholders, such as business-area owners (who may be paying for the system being built), executive management, and resource and other managers, should also attend. Their feedback is essential to ensuring that the team is progressing toward an economically sensible outcome.
It’s a good idea to at least periodically include external stakeholders, such as actual customers or users of what the team is building. With them in the room, the team can get direct feedback instead of indirect (or proxy) feedback via internal stakeholders.
Although the Sprint Review is an informal activity, the Scrum team has some minimal prework to complete This prework includes determining whom to invite, scheduling the Sprint Review, confirming that the sprint work is done, preparing for the Sprint Review demonstration, and deciding who will lead the meeting and who will give the demo.
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 to inspect and adapt and to develop transparency.
First and foremost, the Scrum Team processes feedback on 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 is directly quoted from the Scrum Guide with added emphasis.
-The Product Owner explains to the stakeholders which 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.
Daily Scrum
In the Daily Scrum, the Development Team synchronizes the on-going activities and creates a plan for the next 24 hours (Daily Plan) to drive its development work. Also, any impediments are updated to the Backlog of impediments and made transparent, so others including the Scrum Master will know the details even if they do not attend the Daily Scrum.
