What is the difference between a sprint review and a sprint retrospective?
In the scrum framework, a scrum master hosts and facilitates a number of events during the sprint.
In this short video, John McFadyen talks about the difference between a sprint review and a sprint retrospective, and how a scrum master can get the best out of both scrum events.
A sprint review happens at the end of the sprint and it’s the second last meeting in the sprint sequence. A sprint retrospective comes last.
The sprint review focuses on the product that we are building. This is what is referred to as the increment in scrum.
Your product owner is going to invite the relevant product stakeholders to the sprint review to talk about the product and assess the value of what has been created in the sprint.
As a team, you will review what the team set out to achieve versus what they actually achieved, and also explore the reasons why that gap exists.
Some people may think this may be a bit of whine but instead, it is a team speaking openly and honestly about the challenges they face and highlighting what needs to happen for those impediments to be removed.
A sprint review often consists of stakeholders who have a lot more power and authority in the organisation than members of the scrum team so it is a great opportunity for them to learn what is preventing the team from achieving their goals and how they can assist the team with those issues.
The team also focus on the product itself. In addition to reviewing what has been created in the sprint, it is also an opportunity for the team to illicit feedback on what has been built or the problem that has been solved.
This is what differentiates a sprint review from a demo or a show and tell. The team are actively looking to engage the product stakeholders in a conversation to understand whether they are building the right thing, in the right way, and in alignment with what customers most value.
It is very product focused rather than technical focused. It isn’t a meeting about how the team have achieved their objective; it instead focuses on what has been done and why that matters.
This is the core of the review.
We then focus on governance. The team speak about where they are going next and illicit feedback on what the team will focus on in upcoming sprints and the general direction they are going to follow.
A sharp team will be able to forecast what they are attempting in the sprints to come and provide product stakeholders with an idea of when they will be tackling some of the most important elements on the product roadmap.
So, a sprint review is focused on the product and on getting valuable feedback to inform what is being built, why it is being built, and how it will be built.
The sprint retrospective focuses on the process.
The sprint retrospective will only feature the scrum team and provide them with an opportunity to discuss how they are working as a team, what skills they currently have and what skills gap potentially exist, and anything that helps the team understand how they can improve.
It is a private meeting.
It isn’t an opportunity for line managers or stakeholders to come observe where the team are at and what challenges they are addressing, it is instead an opportunity for the team to speak with freedom and psychological safety about what they are experiencing and how they can improve.
If the team are happy for outsiders to join the conversation, that is fine. If anyone on the team is uncomfortable with external guests, you’re simply going to stifle conversation and prevent the team from exploring the topics they need to be having tough conversations about.
This is an opportunity for the team to explore any mistakes that occurred and to address how they are going to remedy those mistakes and prevent them from occurring again.
The team will explore how they can improve in the next sprint and how they can improve their processes and systems to ensure there is continuous improvement in each sprint.
You’re actively seeking at least one, actionable item that the team can address to help them improve.
It doesn’t need to be the most urgent nor does it have to be the most important, I often recommend that it is something which the team are interested in and actively engaged around. This helps ensure that the item gets addressed and the team implement whatever needs doing to solve that problem.
I really like creating experiments in sprint retrospectives. The team discuss a hypothesis, and they discuss what they intend to do to prove or disprove that hypothesis. The team will also agree on how they are going to measure the success or failure of the experiment and commit to getting it done.
You are focused on the processes. You are also focused on the skills element. Maybe something went wrong or couldn’t be achieved because the team lack the necessary skills.
A sprint retrospective is a great place for the team to discuss which skills are needed and make a decision around who is going to acquire those skills and how they will acquire them.
Sometimes, an item that the team were proud of just got ripped to shreds in the sprint review. The sprint retrospective will be an opportunity for the team to discuss how they can improve and ensure they are working in alignment with product owners, product stakeholders and customer expectations.
You need your team to be open, honest, and focused on improvement.
So, that is essentially the difference between the two. A sprint review focuses on the product whilst the sprint retrospective focuses on the process.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.
If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction to Coaching course page.