Sprint Reviews vs Sprint Retrospectives

Home
TemplatesBlog
Ruth Hadari
Ruth Hadari
Agile Advocate, Engineering Ops Expert
Posted on
Nov 8, 2021
Updated on
Mar 26, 2023
Table of Content

Although the terms “sprint review” and “sprint retrospective” sound pretty similar, the two different meeting types are incredibly different! 

The average developer might not even know the difference between the two, but experienced scrum teams will keep processes in place to ensure that they hold separate review and retro meetings. This will help the team draw benefits from both of these very different but equally important meeting formats!

What Do You Need to Know About Sprint Reviews Vs Sprint Retrospectives

While in usual, every-day occurrences, the words ‘review’ and ‘retrospective’ would mean the same thing, when it comes to a sprint these are divided into separate events: 

  1. The ‘review’ handles the team and stakeholder actions
  2. The ‘retrospective’ handles how the process has taken place

One is more about the people involved, and one’s more about the process

Sounds confusing? It needn’t be. Here’s a quick rundown of the goals, structure, and ideology behind both sprint reviews vs sprint retrospectives! 

The Sprint Review

How Often Are Sprint Reviews Conducted or Held?

Sprint reviews are held at the end of each Scrum sprint. All of the key people and stakeholders should be present for it to be truly effective. 

It could last anywhere from 1-4 hours per sprint, depending on the length of the sprints taking place.

Since the sprint review frequency is affected by the length of the team's sprint, which can last between 2 to 4 weeks, one can expect a sprint review to be conducted up to 2 times a month.

What is the Purpose of a Sprint Review?

The objective of each sprint review is to discuss the previous sprint’s goal, the product delivered, and possible improvements for the next sprint. If your team isn’t getting each of these benefits out of your sprint review meetings, you’ll want to go back to the drawing board and figure out how to revamp your process. 

What Topics Should Be Discussed in a Sprint Review?

Sprint Reviews are usually divided into 3 important sections: 

  • Demonstration: the development team demonstrates what has been achieved during the sprint, or, for less technical products, the product owner might be the lead person demonstrating results. 
  • Discussion: stakeholders give their feedback on the demonstration that’s taken place, and ask questions, discuss progress, or provide some further business context to development teams. 
  • Product backlog update: this is where the preparation for the next sprint comes into focus! The team will likely start prioritizing the rest of the product backlog (also known as scrum artifact), adding new information (such as user stories), properties or descriptions, linked tasks and so on.

The Sprint Retrospective

When is a Sprint Retrospective Meeting Held?

Sprint retrospectives, like sprint reviews, are also conducted once a sprint has finished. However, the retrospective is always held after the review. 

What is the Purpose of a Sprint Retrospective?

The ultimate goal of a sprint retrospective is to get honest, open feedback from every team member, as well as an action list, to improve the next sprint. They might be shorter than sprint reviews and even held once for every week of a sprint. 

Sprint retrospectives, like sprint reviews, are also conducted once a sprint has finished (the retrospective is always held after the review)– but that’s where the similarities between the two end! The sprint retrospective is just for the scrum team itself and focuses on how to improve their way of working for the next sprint. 

What Topics Should Be Discussed in a Sprint Retrospective?

Some of the most important questions to ask include: 

  • What went well last time, and why? 
  • What could have been better, and how? 
  • What do we need to do to improve the next sprint (including action items). 

The effectiveness of the sprint retrospective is entirely up to the team involved: for example, if one member explains how they didn't meet their goals due to sudden and unexpected extra work coming in, it would help the rest of the team going forward in prioritizing tasks. 

How Long is a Sprint Review Compared to a Retrospective?

Compared to a sprint retrospective, a sprint review is generally a shorter, less-involved meeting. For a two-week sprint, most teams try to constrain their retrospective meetings to a 90-minute window; sprint reviews in this situation are kept to an hour. For a sprint that lasts a month, both of these values can be doubled. 

How to Make Sprint Reviews and Sprint Retrospectives Interesting?

If you want to make sure that your team’s sprint reviews and sprint retrospectives stay engaging, interesting and productive, start off with some fun icebreakers for the team to ease in! Make sure to also keep an eye on your agenda and time! Now, you’ve got two surefire ways to turn your sprint retrospectives and sprint reviews into effective methods of keeping your teams involved and motivated.

Sprint Reviews Vs Sprint Retrospectives: the Bottom Line

While there are quite a few similarities between sprint reviews vs sprint retrospectives, like how they: 

  • both take place after a sprint has finished
  • they’re focused on issues, not people 
  • are there to make the next sprint more effective

….there’s still a lot more to these two key scrum events

Focusing on the key elements (such as how to make the next sprint bigger, better, faster, and stronger) and avoiding apportioning blame is key to both of these events.

In both, the team needs to feel: 

  • That they’re in a safe and supportive environment, without fear of blaming or retribution
  • That anything discussed (problems, challenges, failures, and more) are focused on issues encountered, not the actual people involved. 
  • Fresh from the past sprint: both sprint reviews and sprint retrospectives need to happen quickly after the end of the sprint, so it's fresh in all participants’ minds. 


About the author

Ruth Hadari
Agile Advocate, Engineering Ops Expert

Highly experienced in leading multi-organizational teams, groups, in-shore as well as off-shore. The go-to person who is able to simplify the complex. An agile advocate, experienced in all common methodologies. Responsible for the entire software development lifecycle process from development, QA, DevOps, Automation to delivery including overall planning, direction, coordination, execution, implementation, control and completion. Drives execution, and communicates on status, risks, metrics, risk-mitigation and processes across R&D.

Related Posts

Contact Us
Thank you! Your message has been sent!
Oops! Something went wrong while submitting the form.
Close