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.
Table of contents
- What is scrum?
- What are the five scrum events?
- Sprint review vs. sprint retrospective
- What is the purpose of a sprint review?
- What is the purpose of a sprint retrospective?
- What is the product manager’s role in a sprint review?
- What is the product manager’s role in a sprint retrospective?
- Key differences between sprint review and retrospective
- Tips for optimizing your sprint reviews
- Best practices for running sprint retrospectives
What is scrum?
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.
What are the five scrum events?
The Scrum Guide outlines five events that agile product development teams undergo to run successful sprints. The five scrum events are:
Sprint review vs. sprint retrospective
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.
What is the purpose of a sprint review?
The sprint review meeting has three distinct objectives:
- Showcase and review the product development completed during the sprint — The development team highlights and demos the completed stories and presents any impediments and solutions discovered during the sprint. The demo is the first opportunity for stakeholders to see the requirements in a tangible flow, review the development, and give feedback
- Update the product backlog — Participants discuss the backlog, review the market needs, and reprioritize items as necessary for the upcoming sprint, including implementing any changes in response to the feedback
- Project the release date based on feedback — The product manager reviews feedback and conclusions and discusses the resources, budget, and other dependencies required to solve any impediments to the upcoming sprints
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:
What is the purpose of a sprint retrospective?
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).
What is the product manager’s role in a sprint review?
Organizing the meeting
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.
Setting the sprint review meeting agenda
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:
- Sprint goals
- Completed stories (along with impediments to finishing any incomplete stories)
- Demo (conducted by the dev team)
- Feedback
- Key metrics (including a budget, resources, and KPI discussions)
- Product backlog (update and evaluate top-priority items)
Running the sprint review session
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.
What is the product manager’s role in a sprint retrospective?
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.
Key differences between sprint review and retrospective
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.
Product vs. process
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.
User-centeric vs. team-centeric
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.
Product backlog vs. action list
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.
Product manager vs. scrum master
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.
Tips for optimizing your sprint reviews
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.
Prepare a checklist of the demo
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.
Deliver fact- and data-based feedback
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.
Avoid the blame game
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.
Best practices for running sprint retrospectives
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.
The post Sprint review vs. sprint retrospective: Why the difference matters appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/gYBMhzA
via Read more
