Basic Objectives Of The Sprint Review Meeting In Scrum

By Author: Mrugesh panchal
Total Articles: 48
Comment this article

A sprint review meeting is held just after a sprint ends. The meeting usually lasts for four to eight hours. The duration of the sprint has a lot to do with how long the sprint review lasts, and its time is determined on the basis of the sprint duration. The most significant part of the sprint review is to demonstrate the user stories developed by the team during the daily sprints. Ideally, the team should not invest more than an hour in show casing their sprint activity to the product owner, since time is required to carry out other review related activities by the scrum team.

In most cases, the review is held on the last day of the sprint, or the day immediately succeeding it, if it is a working day. The main purpose of the meeting is to exhibit the tasks to the product owner and the scrum master. The scrum master plays a passive role during the review, and is primarily responsible for facilitating the meeting rather than taking an active part in it. The product owner reviews the user stories developed during the sprint iteration, and verifies whether the product backlog items ...
... are developed in a manner such that they satisfy the acceptance criteria defined by the product owner when the product backlog is created by him or her during the project inception.

Primary objectives of a sprint review meeting
The objective of the review is to:

• Display the work carried out during the sprint to the product owner.
• Have the user stories accepted as “done” provided they fulfill the acceptance criteria.
• Adjudge whether the development team has delivered work as per commitment.
• Determine whether the tasks have been developed as per instructions given to the team members during the sprint planning meeting.
• Find whether the team faced any problems while the sprint was underway. If so, what were they?
• Support the self-learning feature of scrum and find what lessons can be learns from the sprint just carried out.
• Estimate the velocity of work carried out by the team during the sprint.
• Decide how to proceed with the next sprint.

Most of the times, Agile teams will ask the stakeholders to accept the work as “done” if the development satisfies the acceptance criteria, and the product owner gives the “green” signal. If the user stories are “shippable”, there is no reason why the investors and stakeholders should delay in accepting them as final and done. Even though there is an entirely separate meeting – the sprint retrospective meeting – to carry out the same activity, the basic intention is to save time during the retrospective, and utilize the “extra” time to discuss issues that are more important. Each event in scrum is time boxed. The team is always pressed for time, and tries to take the maximum benefit of available time.