When all the hard work of the current sprint is completed, it’s time to wrap up and prepare for the next one. Two processes that are beneficial to the team’s productivity and skill development are sprint reviews and sprint retrospectives. At first glance, these two official Scrum ceremonies look similar, but they're actually quite different.
What is a sprint review?
Sprint reviews take place after the sprint goal has been met, and before the next sprint planning session. The goal of each sprint is usually a functional increment, or deliverable. People who should attend these meetings are the stakeholders, Scrum Master and team, and the product owner. These meetings shouldn’t be any more than 4 hours, to keep them from being tedious. 2 to 3 hours should be enough to cover all the relevant topics.
Sprint Review Structure
During this portion of the meeting, the developers or the product owner will present all the tasks the team completed during the sprint. Only increments that are ready to be released or implemented into the overall product are presented.
The stakeholders, after seeing all the finished increments, are free to ask questions or provide feedback about the progress so far. During the discussion stage, there are three objectives to focus on.
Progress analysis - The Scrum team explains what exactly they did during the sprint, as well as any unfinished tasks. If applicable, they also explain the reasons for any unfinished work.
Market presentation - It’s the stakeholders’ turn to present now. The Scrum team explains the technical side of things, whereas the stakeholders explain the current market landscape and customer insights.
Motivation - This stage serves to motivate the Scrum team with positive facts and market projections so that they'll start the next sprint with enthusiasm!
Once the stakeholders discussion is over, it’s time to update the backlog. This step is crucial because it provides structure and organization to the remaining increments that are to be completed. The product owner and Scrum Master add or remove user stories, and reprioritize the backlog items before choosing what the team will work on in the next sprint. The team uses different backlog prioritization techniques to achieve that. Read more on this process in the "Epic, Story, and Tasks in Agile" article.
What is a sprint retrospective?
As a part of the sprint cycle, sprint retrospective meeting also takes place between sprints, but it always comes after the sprint review. Those who should be at the meeting include the Scrum master, product owner, and the Scrum team. Thankfully, the retrospective meetings are shorter, usually lasting between 30 minutes and 3 hours. The purpose of a retrospective is quite different from a review. Rather than focusing on details of the project, this Scrum ceremony is to examine the team’s work styles and what areas they can improve in.
Sprint retrospective topics
There are three open-ended, existential questions that make up a sprint retrospective. Each team member must provide feedback for every question, if they can. This way, everyone has input and feels encouraged to share their thoughts. The questions are quite simple.
What went well?
What didn’t go so well?
What can we do to improve?
It’s easy to get answers to these questions and move on; the real challenge that many teams face is actually using the insights to make change. To make these meetings worthwhile, they must also make an action list. An action list is basically a list of the issues, and the things people can do to move towards solving them. Though this process is helpful for many, some choose to opt out entirely.
The problem with retrospectives
While retrospective meetings can be helpful to many teams, others choose to have them less often, or not at all. There are a few commonly reported reasons for this.
Tension or arguing - Sometimes people don’t respond to criticism well, or people fall into playing the blame game. Obviously, this is unpleasant for all parties, and could harm the team’s relationship rather than help it.
Takes too long - People may feel that having an hours long meeting takes too much time away from their other work.
Too repetitive, lacking ideas - The structure of the meeting might be tedious for some, who ran out of ideas on how to improve long ago.
Feeling unheard - If the team leaders or other members fail to use the ideas suggested in the last meeting, and nothing changes, people find that frustrating and demotivating.
To sum up, every team is different. The Scrum master knows their team best, and will make the best decision based on their needs.
As you can see, on the surface reviews and retrospectives sound similar, but they’re completely different. Here’s a summary of the biggest differences between the two.
Perhaps the most crucial difference between these two Scrum ceremonies is their main objective. A sprint review is to share insights and progress about the project, whereas a retrospective probes the team itself and how they work.
At a retrospective meeting, the Scrum team, Master, and product owner are present. In contrast, all those parties and the stakeholders, plus anyone else who may be needed, are present at a review session.
Length and frequency
The duration of sprint retrospectives depends largely on the team itself, and can last between 30 minutes and 3 hours, and some teams never have them. Reviews are usually between 2 and 4 hours, and should never be skipped.
Just like the purpose of each ceremony is different, so too is the end result. The result of sprint review is more knowledge about the project and current market trends, a vision for the next sprint, and an organized backlog. The results of a retrospective should have an action list, and more insight into how team members work together and as individuals.
Blocshop provides custom-made software to businesses across the globe using certified Agile practitioners. If you or your company are interested in learning more about what Blocshop can do for you, have a look at our customer testimonials.