The sprint review and sprint retrospective are commonly conflated. In reality, these two scrum ceremonies are quite different in a variety of ways, including their focus, where each falls within the sprint cycle, and what goes on the meeting agenda.
As a product manager, failure to understand the distinction can result in misaligned and inefficient teams.
Each event in the scrum framework has its purpose and a timeline for when it should occur during a sprint. Understanding each event’s objective is critical for achieving total efficiency and continuously improving the scrum team’s performance.
Quick delivery, continuous learning, and iteration-based development are among the core principles of agile product development. Scrum is one such framework that enables agile teams to achieve rapid delivery cycles. Therefore, to ensure that your team fully benefits from the scrum framework, it’s essential to understand the value and purpose of each ceremony.
The Scrum Guide outlines five events that agile product development teams undergo to run successful sprints. The five scrum events are:
The primary objective of a sprint review is to improve the product, whereas the goal of a sprint retrospective is to improve the process. Clearly, skipping either of these events would drastically hinder improvement, learning, and growth opportunities.
If we were to picture the scrum framework on a linear plane, the sprint starts with sprint planning. Then, daily standups occur on each day of the sprint. A sprint review is conducted during the final days of the sprint, followed by a retrospective. Backlog refinement can be performed anytime during the sprint as needed.
The sprint review meeting has three distinct objectives:
The outcome of the sprint review meeting should evolve into the backlog of the impending sprints.
Here is a sprint review template to help you visualize a typical meeting agenda:
The sprint retrospective strives to assess the necessary improvements for the team to enhance their performance and achieve maximum efficiency. During the sprint retrospective, the group discusses what went well to help it reach the sprint goal and what didn’t go well that can be improved upon in the upcoming sprints.
Also in this meeting, the scrum master can help guide the team to reach a healthy discussion about how to enhance their ways of working.
The sprint retrospective template below groups discussion items into three categories: Liked (what went well during the sprint), Disliked (what did not go well), and Learned (things to improve on).
It is the product manager’s responsibility to organize the sprint review meeting and invite all the relevant participants — e.g., stakeholders, user experience designers, data analysts, and the development team.
Usually, the sprint review meeting occurs at the end of the sprint. Depending on the length of the sprint, this session can last from 30 minutes to half a day.
There is a lot to achieve during a sprint review meeting. The product manager should time-box all activities and attach the meeting agenda to the invitation.
A typical sprint review meeting agenda includes the following:
One of the most important objectives of the sprint review meeting is to demonstrate the work completed during the sprint — this is usually presented by the development team. The team may also highlight impediments and solutions implemented during the sprint.
Once the demo is complete, the product manager facilitates a session for the stakeholders to provide feedback and review the development in terms of user needs. The product manager is responsible for collecting the most valuable feedback and adding it to the backlog for upcoming sprints.
The product manager may also discuss and evaluate the market needs if they have shifted from the original initiation of the product design. This helps keep the product backlog relevant and updated.
Sprint retrospectives are organized and run by the scrum master. However, product managers should also participate because healthy discussions are most likely to occur when every team member is present.
Fostering productive discussions and an open environment in which everyone is empowered to speak is the responsibility of every participant in the sprint retrospective. That includes product managers. Remember, the No. 1 agile value as described in the Agile Manifesto espouses individuals and interactions over processes and tools.
The table below lists some key distinctions between the sprint review and sprint retrospective ceremonies.
| Sprint review | Sprint retrospective |
| Scrum team and stakeholders attend | Only the scrum team attends |
| Goal is to present work to stakeholders and gather feedback | Goal is to improve efficiency for the next sprint session |
| Sprint reviews finish items from the product backlog | Sprint retrospectives create tasks to improve workflow |
| Discusses what the team is working on | Discusses how the team is working |
Let’s dive into more detail and look at some specific ways in which a sprint review differs from a sprint retrospective.
The sprint review is focused on product development, whereas the sprint retrospective is focused on process improvement.
To create an effective, functional, technically sound, and user-centric product, you need all stakeholders and developers to align in the sprint review meeting. Therefore, having a product mindset during the sprint review is essential.
By the same token, you need a people-process mindset to reflect on what is working in the team’s favor and what can be improved to make your teams as efficient and high-performing as possible.
The sprint review is user-centric, whereas the sprint retrospective is a team-specific event.
During the sprint review, the product manager and stakeholders have an opportunity to discuss and describe the market landscape and customer insights with the development team. This helps the team understand the value of the development process and motivates developers to make the change. These discussions are data- and research-driven.
During the sprint retrospective, scrum masters and other team members discuss which processes are working in the team’s favor and review factors that can be improved to increase efficiency. The discussion is intimate and can include personal opinions related to ways of working.
The outcome of the sprint review meeting is an updated product backlog, whereas the outcome of the sprint retrospective is an action list.
Feedback gathered from the stakeholders during a sprint review is added to the sprint backlog, along with other requirements based on customer insights and market changes.
After the sprint retrospective discussion, a list of actions is derived to improve ways of working and maximize efficiency within the team. Each team member then follows these actions in the upcoming sprints.
The product manager runs the sprint review, whereas the scrum master runs the sprint retrospective.
A product manager has to arrange and facilitate the sprint review meeting, set the sprint review meeting agenda, and follow up on the meeting outcome. Additionally, the PM must ensure that the backlog is updated after the discussion and possibly predict the release date based on comments and feedback received.
The scrum master is responsible for setting the agenda for the sprint retrospective, encouraging healthy discussion about the good and the bad, and building an actionable list for improvement. The scrum master is also expected to be a scrum coach and ensure that the team members follow the actions in the next sprint.
Product managers act as a bridge between stakeholders, end users, and the development team, and they have full authority over the product backlog. An objective and perfectly groomed product backlog is crucial to sprint planning and successful product delivery.
The sprint review helps the product manager ensure alignment between the development team and stakeholders to achieve great results. Therefore, it is in the best interest of the product manager to make sure the sprint review is executed optimally.
Below are some tips for running more efficient and effective sprint reviews.
During the demo, the system can break, test cases can fail — really, anything can happen. The only certainty is that the sprint review will never go exactly as you would like.
To avoid any delays or complications during the demo, try to have a checklist prepared beforehand. Check whether the system works and confirm that everything is deployed and test cases are well-prepared. If possible, rehearse the demo beforehand.
It’s not uncommon to see a feedback session about corner case scenarios devolve into a discussion about main cases. Corner cases occur when a very small percentage of your user group ends up using the feature in unintended ways.
To avoid jarring shifts in focus, time-box the discussion and ask for participants to cite facts and data to support each piece of feedback. Anytime a stakeholder starts a sentence with ‘’I have a feeling,’’ try to contextualize it by citing the proportion and percentage of users affected.
You will be pleasantly surprised by how quickly unnecessary discussions die out when you try to put it in context with data.
During discussions about budgets, resources, backlog prioritization, and even development, people tend to place blame elsewhere.
Whenever something like this starts to happen, remind everyone that you are all working toward the same goal of implementing something that will be useful for your users. If time or resources are constrained and priorities shifted as a result, the team will be better equipped to understand that it all comes with good intentions for your users.
One of the hardest things to do as a product manager in a sprint retrospective is to keep an open mind. Open thinking sounds simple and logical, but it’s hard to avoid feeling personally attacked when constructive criticism is directly addressed to you.
Retrospective discussions are critical to improving the efficiency of the business. However, sometimes these actions can be directly related to the work you do for your team.
Try not to take this feedback personally. See yourself from an objective, third party perspective outside the discussion. To be objective, you should look at what needs improvement in the role of the product manager, and try not to see yourself in it at all.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
