How Sprint Reviews Are Different From Sprint Retrospectives In Scrum?

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

Even experienced Agile scrum teams can get the sprint review wrong, at times, as far as its interpretation is concerned. People still tend to call it a “demo” or a “showcase” simply because the user stories developed during the daily sprints are exhibited to the product owner for approval. This is wrong, and far removed as far as the objective of the review is concerned. Ideally, the sprint retrospective should be referred to as a “demo” since the approved user stories are showcased to the stakeholders and project owner to ascertain whether they meet their acceptance criteria, and are in fact “shippable”. The review and the retrospective have specific objectives and functions to play – they should not be linked together.

Sprint review meeting
The main objective of a review is to find whether all user stories included in the sprint backlog have in fact been completed, and if so, do they satisfy the acceptance criteria? In certain instances of scrum implementation, the review may not be so elaborative since the product owner may start approving and ...
... rejecting the user stories as soon as they are completed while the sprint is still under process. In such cases, the review may be very short and held primarily for getting a feedback from the team as to what worked well and what did not during the sprint. One of the primary objectives of the review is to inspect, and learn from prior sprints. The stakeholders do not attend the review.

Sprint retrospective meeting
The primary reason of holding the retrospective is to showcase the development approved by the product owner to the stakeholders. A feature or functionality may be correctly developed by the team, but it remains to be seen whether the stories still maintain their business values. Generally, the importance of the user story to be developed is explained in the acceptance criteria when the product backlog item is defined in the product backlog immediately after the release planning. However, the project owners still need to satisfy themselves whether the stories meet their expectations. User stories are considered “shippable” once they are approved in the retrospective. Another objective of the retrospective is to carry out the brain storming sessions and find ways to improve the current scrum process. This is usually done by introspecting prior sprints, and finding out how things can be further improved upon by studying the difficulties faced by the team in the past. This meeting is very important since it is attended by end users, marketing team, and even retailers in certain cases. These entities provide reliable feedback about the current market scenarios and how the user stories developed by the team are likely to fare in the market once the product is completed.