Sprint Review vs Sprint Retrospective: The Critical Difference

Sprint review and sprint retrospective may sound a bit similar, especially if you’re just starting to use scrum as your Agile product management framework. Even experienced scrum teams sometimes don’t know the difference and either run only one of the meetings, or worse: merge them into some weird and often detrimental combination.

But there’s a huge difference between the sprint review and sprint retrospective because both meetings serve completely different purposes. 

In a nutshell, the sprint review is about the product, while the sprint retrospective is about the team. While the sprint review helps you to regularly meet customer expectations, retrospectives allows scrum teams to become faster, smarter, and even happier. And that’s just scratching the surface.The sprint review is about the product, while the sprint retrospective is about the team.

Focus on the process and deliverables for every meeting, and the sky is the limit to how productive and engaged your team can become. 

Let’s dive into the whole scrum sprint review vs sprint retrospective confusion and learn what makes both meetings uniquely useful and integral to the scrum framework.

The sprint review is one of the five pivotal scrum ceremonies. It is held at the end of each scrum sprint. During the sprint review, the scrum development team, product owner, and business stakeholders gather together to discuss the sprint results. 

Some scrum teams mistakenly label the sprint review meetings as a “demo” or “show and tell” meeting where they demonstrate and list out what was achieved during the sprint, but demonstration is just one aspect to this Agile ceremony. 

The whole meeting is timeboxed to last from one to four hours, depending on how long your sprints are. For example, if you are using one-week sprints, the meeting should last no longer than one hour, and if you’re using sprints that last a month, the sprint review should last no more than four hours.

The sprint review consists of three equally important parts:


Sprint Review Part #1: Demonstration

During the demonstration part, the development team presents what was done during the sprint.The nature of scrum dictates that the team can only present finished products or product increments that are ready to be put onto production. 

For a less technical product, or less technical stakeholders,  a product owner may demonstrate the sprint results instead of the developers. 

Sprint Review Part #2: Discussion With Business Stakeholders

After the development team or the product owner presents the results of the sprint, the business stakeholders give their feedback to and ask questions about the finished product or increment to the scrum team. 

Here are three main goals the sprint review discussion should achieve: 

  • Progress overview. The scrum team helps stakeholders to understand what was done during the sprint, and what was not completed (where relevant). They may also want to offer some level of explanation around why the sprint goal was not met (for example external factors became a blocker to them).
  • Extended business context for developers. Business stakeholders and the product owner share with the developers the current market landscape and customer insights to hint at what might be the next development goals.
  • Motivation for scrum team. When stakeholders provide developers with feedback and customer insights they motivate scrum teams to perform even better, showing that their work has impact and meaning.

During the sprint review discussion, business stakeholders may also provide additional context for developers in terms of general timeline, budget, and capabilities. This can be done to help the scrum team better understand their development environment and enhance their efficiency. 

Sprint Review Part #3: Product Backlog Update

During or after the sprint review discussion the product owner may update the product backlog, prioritizing user stories, updating their descriptions, adding new user stories, or removing them from the product backlog altogether.

Updating the product backlog and discussing priorities during the sprint review certainly affects what the scrum team will be working on during the next development cycles as the team usually works on the user stories  with the highest priority.

The sprint retrospective is also one of the core scrum ceremonies, and just like the sprint review it’s conducted after the sprint is finished, and this means ‘really finished’, so after the sprint review too. 

But this is where the similarities between the sprint review and sprint retrospective end, because the sprint retrospective has completely different objectives. During the sprint retrospective, the scrum team  gets together to inspect their ways of working during the last sprint, and decide how they can improve during the next sprint. 

In order to do that, one of the most common ways to structure a sprint retrospective is to have every team member answer the following questions: 

  • What went well?
  • What did not go so well?
  • What actions need to be taken to improve?

But simply answering the questions won’t make your team more productive. You need to keep your retrospectives actionable and engaging, and to-the-point. 

The goal here is to receive honest feedback from every team member on every question and then turn this feedback into an action list containing specific steps that the team intends to take to enhance their performance during the next sprint.

For example, during the retrospective you learnt that the team think they might have a problem with unexpected work: that they couldn’t meet the sprint goal because a lot of unexpected work was coming in from outside the team.

Knowing that the team wants to get smart on this, the Scrum Master might create an action item to record details of any unexpected requests in the next sprint so that the team have the data to know where it’s coming from and what the impact is. A follow-up action might then be to come up with processes or agreements to reduce that unexpected work. 

Unfortunately, some scrum teams tend to skip retrospective meetings for the very same reason: they struggle to make them actionable. 

But there are several other reasons why teams often skip this meeting:

  • It becomes more of an argument (finger pointing session) between the team members. This makes it an unpleasant session and people no longer want to attend.
  • The actions from last time aren’t carried out, so people think it’s a waste of time to make the list.
  • The format gets repetitive and boring, and it no longer gets the best out of the team when it comes to them coming up with ideas on how to improve.
  • It frequently overruns and the team think it’s too much of a time investment. They’d rather be getting on with the job. 

For all these reasons, experienced scrum teams often turn to online retrospective tools or blogs and forums etc. for ideas on how to organize their retrospective meetings, keep them productive, and above all keep them engaging for the team. If your team is remotely distributed and uses Slack, one of the most effective ways to conduct actionable retrospectives is to run them directly in your Slack channel. 

For example, Geekbot allows every team member to answer the retrospective questions mentioned above in Slack (either anonymously or not) and then automatically stores all the answers in the dedicated Slack channel where you can analyse them. 

With Geekbot you can also customise questions to better fit your team culture. You can add additional questions, make them more specific, or experiment with the format to make your retrospectives more engaging.

For example, instead of asking “What did not go so well?”, you can try asking “What was the biggest challenge during the last sprint?”

Difference Between Sprint Review and Retrospective

By now it should be apparent that the sprint review and sprint retrospective serve completely different purposes.But let’s cover in detail the difference between the sprint retrospective and the sprint review across three different dimensions. 

Sprint Retrospective vs Sprint Review Difference #1: Participants

The first thing you notice when conducting both meetings is that the sprint review involves almost anyone related to the product, whereas the sprint retrospective is a ceremony for the scrum team alone, with no input from any other 3rd parties. 

  • Sprint Review participants: Scrum team (including the scrum master and product owner), various business stakeholders
  • Sprint Retrospective participants: Scrum team (including the scrum master and product owner)

Sprint Retrospective vs Sprint Review Difference #2: Deliverables

Although both meetings are held after the sprint ends, the outputs of each meeting vary greatly. 

  • Sprint review output: updated product backlog with the top priority user stories for the development team to work on at the top
  • Sprint retrospective output: action list with specific steps to improve team ways of working during the next sprint

Sprint Retrospective vs Sprint Review Difference #3: Goals

  • Sprint review purpose: alignment between the scrum team and product stakeholders, and provide the scrum team with a general path for development
  • Sprint retrospective purpose: consistently improve scrum team performance from sprint to sprint 

Making The Most Out Of Both Meetings

The easiest way to make the most out of these two scrum ceremonies is not to merge them together. Each meeting, both the sprint retrospective and review, has its clear purpose and agenda. Both of these meetings ensure that the scrum team operates at their fullest potential, but they do that in their own, unique way. Focus on the process and deliverables for every meeting, and the sky is the limit to how productive and engaged your team can become. 

If you want to run effective scrum retrospectives and daily standups directly through  Slack and keep your level of team collaboration and engagement at an all-time high, try the 30-day trial Geekbot

We developed Geekbot to keep our own remote distributed team happy and effective, and now thousands of teams all around the world trust Geekbot to do the same for them!

Leave a Reply

Your email address will not be published. Required fields are marked *