Sprint Review vs Retrospective

Sprint review and sprint retrospective. Sounds a bit similar, right?

Both are critical parts of the Scrum project management methodology and are referred to as Scrum ceremonies. They are, essentially, meetings that the Scrum team runs during every sprint.

Download PDF

And even though it is tempting to call them the same thing, it would be terribly incorrect to do that. There is a huge difference in those meetings’ purposes, and today we will tell you all about them so you won’t get confused anymore.

Before we compare the two Scrum ceremonies, let’s look into each one individually and define the key goals, formats, and purposes.

What is a sprint review?

The sprint review meeting is a Scrum ceremony held at the end of a sprint. It is scheduled in the team’s calendar planner and attended by the development team, Scrum Master, product owner, and stakeholders. The standard duration of the session ranges from 1 to 4 hours depending on the Scrum sprint length.

Key activities are:

• Product demo.
• Discussion and feedback sharing.
• Product backlog updates.

The goal of the sprint review is to present and discuss sprint results (in the form of potentially shippable product increment). The Scrum team gives context to the end result and discusses the solution with business stakeholders.

The sprint review does not necessarily have to be limited to the product increment presentation and feedback sharing. Because key stakeholders attend it, it is essential to take this opportunity to catch up in general on the sprint goal and the development process. Later, it can be further discussed by the Scrum team during the sprint planning meeting.

Main elements of the sprint review

While not a must, many teams like to follow a certain structure. The typical sprint review consists of four clear steps: catch up on the sprint, the demo, analysis, and product backlog review. Let’s look into each one in more detail. You can always use project management tools for remote teams to work in a team with remote employees.

Step 1: Catch up on the main objectives of the sprint

In the beginning, the product owner or a member of the team reminds the participants of the sprint goal and the key user stories worked on during the sprint, what tasks and jobs were assigned and why. Then followed by a quick update on what was completed, what wasn’t, and why.

Step 2: The demo

The demo is often considered the central activity of the meeting, although it really depends. Ideally, the Scrum team presents the product in action and allows stakeholders and everyone else to play with it. With software solutions, it could be carried out via giving access to the beta version. Formal presentation with slides should be avoided at all costs as it brings less value and is not as insightful.

Tip: Start with a small ice breaker to loosen everyone up before the demo starts. Chances are you’ll all have more fun during the meeting and less non-essential comments about the product.

Step 3: Analysis

Once the demo is over, all participants get to exchange their thoughts, complaints, and feedback about the product and the performance of the development team. It is done with the evaluation criteria that are usually agreed on at the beginning of the project.

Step 4: Product backlog review

The last part is going through any changes or updates in the product backlog. Sprint review is a great time to review the backlog because that’s when stakeholders attend and can provide their perspectives. They are not usually welcome at other Scrum ceremonies, and if they are, it’s in a listen-only mode. So, the sprint review is almost a unique opportunity to speak with other stakeholders besides the beginning and the end of the project.

What can be discussed:

• New requirements came up along with the new opportunities.
• Changes to the existing user stories (due to personal preference or a change in the market).
• Reprioritizing existing user stories.
• Canceling out some parts that are no longer relevant or important.

Tip: For more on task prioritization, read the detailed blog post that Bordio team compiled based on experience and experts’ advice.

Backlog review has to be kept brief and to the point. The focus is on what the stakeholders, business users, and other non-team members can say. The Scrum team will have a chance to discuss everything in detail during the backlog refinement session later.

Pro tip: don’t limit feedback exchange to a certain part within the sprint review meeting. Agile methodology (which Scrum is a part of) encourages openness, flexibility, and thought exchange at all stages of the process.

Help sprint reviews be helpful and useful for everyone

Not every sprint review meeting is equally great. Use our tips below to make the most of your review sessions and elevate the Scrum teams’ experience.

Stick to the agenda

Follow the agenda and avoid active team management during the ceremony! We are here to work on the product increment, not exercise management practices or get managed by someone. Any non-review and non-sprint issues must be dealt with elsewhere. To easier manage your project work flow use software for work management.

Make sure the meeting does not exceed the set length

Make note of the time during the meeting and moderate where necessary. No one likes long meetings, especially when they were supposed to end 20 minutes ago. Sticking to the timeframes makes the sprint review efficient and shows respect to everyone’s time.

As you are scheduling sprint planning in the online weekly planner, add explicit notes on the timing policy and zero tolerance for meeting overruns. In general, using free project management tools will make any job easier.

Invite everyone and encourage more people to join

The more perspectives you hear, the better progress you’ll have. Sprint review is a unique time in the project when not only the Scrum team comes together but outsiders get to join too. It is a perfect opportunity to hear customer feedback, catch up with business stakeholders, and get inspiration for future sprints.

Keep it informal

Respect the Scrum values and framework but maintain a friendly atmosphere and keep the meeting engaging. Yes, we are reviewing the result of the sprint and presenting it in return for stakeholder feedback. But! There is no need to make it feel like something that agile teams should be nervous about. Also, leave the room for random discussion too (but not too much).

Write down all suggestions

Any idea, critique, or suggestion should be logged to discuss them with the team later before implementing. Ps – a sprint retrospective is a great place for suggestions review. In fact, it’s where you are supposed to discuss those. So, with the sprint review meetings, focus on gathering rather than analyzing. Use a digital to-do list that everyone can access for that. For example, you can use Bordio’s task planner for teams.

If you’d like to learn more about the topic, we did a separate article on the sprint review meetings in Scrum that you can read in our blog.

What is a sprint retrospective?

The sprint retrospective is the last Scrum meeting held in a given sprint. It is attended by the development team, Scrum Master, and the product owner. The recommended timeframe is one hour per 2-week sprint.

Key elements of the sprint retrospective ceremony are:

• Evaluate the sprint (what was not/good, what can be improved).
• Share feedback and insights for the next sprint.
• Inspect the work process to get maximum value in the next sprint.

Key goals of the meeting are:

• Continuous improvement.
• Learning and change-facilitation.
• Turning honest feedback into the action plan.

Put it in your time planner app.

The key exercise of the meeting is asking the 3 questions:

1. What went well?
2. What didn’t go well?
3. What can be changed?

Also put it in your team weekly schedule maker.

Effective sprint retrospective meeting ensures that every team member gets to speak and share their thoughts. If an idea doesn’t come immediately you can discuss it later or write notes in the team’s virtual planner app. Use one of the best task trackers by Bordio for this. Moreover, all ideas are treated equally, so after the three questions are answered by everyone, the group discussion starts and includes all of the comments. The exercise is essential in the Scrum framework but can be intimidating for some at first. However, experienced scrum teams have no problem sharing what’s on their minds and working with others’ thoughts and feelings.

Reasons why sprint retrospectives don’t happen

Retrospectives are notoriously known for being skipped by some development teams. But why?

• They are not actionable. There is a lot of talking and too little doing. Retrospective meetings exist to help the Scrum team get better and continuously improve their development process. Imagine having the whole Scrum team share their pains and creative ideas only to completely ignore them, so nothing gets changed since the previous sprint. It would be demotivating, to say the least.
• Action plans are created but there are obstacles to implementing the new ideas. As a result, the same issues migrate from past meetings to the next one, making it all look like a waste of time. It’s possible that some changes require approval or help from outsiders. And that’s where the Scrum team often faces the wall. Either they are not allocated extra resources, or the issue lies with the process or people that cannot be changed. If that’s the case, then it becomes irritating to discuss the same things over and over again, when everyone is already well aware of the situation.
• It becomes a blame game and finger-pointing rather than a healthy discussion. The sprint retrospective meeting that is toxic is doomed. Technically, sprint retrospectives are not essential in the sprint in the sense that work can get done without it. However, as it fosters curiosity and self-improvement, it is considered one of the essential Scrum events. As you can imagine, if there is a meeting that is highly unpleasant and you mustn’t attend it to get to the sprint goal, there is a big chance of the whole team deciding to drop it altogether.
• The format is boring and not optimized. Maybe you have one speaker doing all the talking, maybe it is very bureaucratic, or every joke gets shut down by a meticulous team member. Whatever it is, find the life-sucking element and remove it as soon as you can.
• The retrospective meeting takes too long and overruns the defined timeframe. Have you ever dreaded going to a meeting that you knew would overrun terribly for no good reason? We all did. It’s not fun. So whenever you run a sprint retrospective (or a sprint review, for that matter) don’t underestimate the importance of sticking to the schedule for yours’ and everyone else’s daily planner’s sake. You should do better time planning in team’s free electronic planner.

Help retrospectives be useful and helpful

Sprint retrospective meeting should feel like a laid-back yet informative conversation, where no one is rushed but a lot gets done in a short time span.

Don’t be tricked into thinking that such a relaxed setup will come naturally. Retrospective meetings take time to master and some preparation is required. Below are the tips to make the most of the ceremony:

• If you are unsure how to run a sprint retrospective, consult with Scrum Master. That’s exactly what their role is: helping the team succeed with Scrum, so never be ashamed to ask for help.
• Focus on positivity. We are not here to find whom to blame for things not going right or to complain endlessly. The goal of the sprint retrospective meeting is for us to agree on the steps to fix whatever is not working and never have this trouble again in the next sprint.
• Before the meeting, ask everyone to think of the feedback, thoughts, and insights. It will help avoid the awkward silences and Scrum team members desperately trying to come up with something. Bonus tip: besides thinking of what to say in advance, ask the team to add action points to their thoughts, so that it’s not just an idea but a suggestion.
• Encourage the entire Scrum team to share their ideas about possible improvements not on the past sprint only but the retrospective ceremony too. You might get great tips and ideas that will change the dynamic of sprint retrospectives for the better.

Use the recommendations above and you will have a team committed to making the most out of the sprint retrospective meetings.

Sprint review vs sprint retrospective: the critical difference summed up

Scrum, unlike traditional project management methodologies, such as Waterfall or PRINCE2, worships flexibility and adaptivity. That’s why you will hardly find two sprint reviews or sprint retrospective meetings that look the same.

However, their core goals and purposes are the same across all companies and industries. So, even if some aspects of sprint review and sprint retrospective migrate back and forth, they are still different by nature.

Here are the core differences:

1. Sprint review focuses on the product (WHAT are we creating), sprint retrospective focuses on the team process (HOW are we creating it).

2. Sprint review helps meet external expectations, whereas sprint retrospectives help the team reach inner goals, such as improvement and advancement.

3. Retrospectives are attended only by the Scrum team that works on the project, sprint reviews are open to third parties.

4. Another difference between sprint review and retrospective is the output. The main outputs of the review are the approved product increment and updates in the backlog. The core output in a sprint retrospective meeting is an action list with steps to improve anything project- and team-related.

Final thoughts on sprint review vs sprint retrospective

The key to having successful meetings is to not Frankenstein them into one. They might look similar at the first glance, but it couldn’t be further from the truth.

Sprint review and sprint retrospective both have a clear format and purpose. They serve the Scrum team and help make the project successful by focusing on certain aspects of the sprint.

Make sure the meetings are positive, short, welcoming discussions but also to the point. Use them as a tool to exercise team building along with achieving the sprint goals. Try the best time organizer by Bordio and become better at planning.