The difference between sprint review and sprint retrospective is one of the most common questions during my Scrum training and coaching. To understand the difference between sprint review and sprint retrospective, let’s understand both of them separately first.
Sprints are the timebox event to produce a part of the product, which we call Increment in the Scrum. It is a time interval to inspect and adapt the product and roadmap. It makes it easy for stakeholders and the scrum team to review the outcome of the sprint.
Sprint is a small project of a set amount of work forecasted by the scrum team at the beginning of the sprint and is an essential part of the Scrum and agile approach.
The Sprint cycle consists of four broad steps, i.e., Sprint Planning, Daily Scrum during Sprint Implementation, Sprint Review, and Sprint Retrospective. Review and Retrospective are the last two stages of the cycle. We call them events in Scrum, but some teams also refer to them as ceremonies.
Sprint Review is a formal meeting between a Scrum team member that includes a Scrum master, a product owner, developers (or development team), and stakeholders. The main motive is to assess the product’s progress and likely completion date. It is also to determine the product’s beginning according to the customer needs and the stakeholder’s expectations.
It gets conducted at the end of the sprint, where participants inspect product increment and adapt product backlog and roadmap. All stakeholders will discuss and access if any changes are required in subsequent Sprints, and decisions may influence product backlog orders.
The purpose is to arrive at an optimized value of sprint. During this meeting, a demonstration of product increment and product backlog takes place.
The Review meeting is generally for 4 hours for a month-long sprint. For a shorter Sprint, the review is shorter. It is headed and led by the Product Owner.
Now let’s dive into the next meeting: Sprint Retrospective meeting happens after the Sprint Review meeting. Sprint Retrospective is the last meeting of the sprint or cycle.
The scope of actual improvement gets discussed regarding people & relations, processes & practices, and the Definition of Done. It can also be called an improvement meeting conducted to identify the potential errors and mistakes in the past and correct them.
It allows team members, including product owners, scrum masters, and developers reflect on the actual product quality, find deviations, and suggest scope for improvement. It is an inspect and adapt event for the Scrum team.
It means that everyone should decide I'm taking a short break, going to a chemist's shop. activities to stop doing, ‘which’ all things the team should be doing in the future, and what ‘more’ should be done to improve the previous processes.
Sprint retrospective ranges from one hour to three hours, depending on the sprint duration and phase of a product. This meeting is all about problem analysis, finding improvement aspects, and correction.
Now, that we are clear on what both the terms mean separately, let’s understand the difference between the two.
Sprint Review focuses on the product, while Sprint Retrospective focuses on the process. Sprint Review is concerned primarily with optimizing and maximizing product value, whereas Sprint Retrospective is involved with people, processes, and tools.
While developing a healthcare insurance product, we discussed our sprint goal which was to “Allow less than 35 years old, non-smoker customer to generate a quote online.”
Next, developers demonstrated working features from the staging server as per the definition of done, and stakeholders provided feedback. Some feedback was crucially related to user experience and performance.
Post feedback, everyone talked about what next to focus on. Does the team continue developing quote features for other groups, or should build to-buy online functionality? Everyone agreed to continue quotes for the family members.
The Scrum team discussed feedback received during the sprint review and discussed team composition, collaboration, and relationships that impacted the sprint result.
The team put all topics individually on board that they encountered or would like to improve. They went through each of them and agreed to take help from a user experience expert and added performance tests as part of the DONE definition.
Besides these, the team decided to peer code review to pay attention to code quality to avoid technical debt.