Guide to Efficient Sprint Review Meetings

Scrum sprint - a quick recap

If you want to know more about Scrum itself, take a look at this article: Building successful apps using Scrum development. Meanwhile, here’s a quick recap of what a Scrum sprint is.

A sprint is a short period of a project in which a new working iteration or increment of the product (i.e. a new feature or functionality) is created. In essence, a sprint is a kind of ‘mini-project’ within the greater whole, and much of the efficiency of the Scrum process comes from each sprint having its own planning and review stages.

The end of each sprint is followed by two meetings of the project team, the retrospective and the review (more on the differences between the two can be found below). For advice and tips on running great sprint retrospectives, see our article: What is a sprint retrospective to learn all you need to know to get started with sprint reviews.

You might be also interested in the article:

Strategy

The great dilemma. Agile or waterfall?

What is a sprint review?

Review literally means to take another look at something. In scrum-powered software development it means, to take a look at the product increment the scrum team has produced and compare it to what the team agreed to aim for in the planning session before the sprint started.

So, what is the scrum team doing exactly during the sprint review?

• Examine the product increment.
• Compare it to the ‘definition of done’.
• Give and discuss feedback.
• Adjust or amend the product backlog, where necessary.

Sprint review vs retrospective – how do you know which one you’re in?

Each sprint ends with two meetings of the scrum team to spend some time looking back (in order to inform and guide looking forward to the next sprint) but what’s the difference, exactly? The answer is that the two meetings focus on different facets of the finished sprint.

Sprint retrospectives are dedicated to examining the process (how did we get here, and can we do it better next time?) whereas the sprint review looks at the product itself (where are we, and is that where we wanted to be?)

Key questions for efficient sprint reviews

Who should attend a sprint review meeting?

This is an easy one: everyone who is directly involved. In other words, the scrum team, consisting of the product owner (especially for feedback and insight into how the increment does or does not address user and business needs), the development team (to present and discuss the increment they’ve been working on for weeks), and the scrum master, whose role is to ensure the sprint review meeting takes place and facilitate where necessary to keep the meeting focused on the product and not on the process or other aspects of the project.

Also, the product owner may invite key stakeholders, those able to offer specific and useful feedback on the product increment.

How long should your sprint review meeting be?

How long was the sprint review? Here at Boldare, we usually work in two-week sprints as we find that time-box to be a good combination of productivity and speed. However, this is something each scrum team should define on their own. The general Scrum rule is that the review meeting should take around one hour for every week of the sprint.

What outcome are you aiming for?

At the end of your sprint review meeting, you should have a revised and refined product backlog with user stories and tasks that reflect the current state of the project. That updated backlog then forms the basis of the next sprint planning session, at which the scrum team decides on which tasks to tackle in the next sprint.

You might be also interested in the article:

What’s the difference between a product backlog and a sprint backlog?

What is the role of the scrum master?

The role of scrum master can often be misunderstood, especially in relation to planning, review, and retrospective meetings. In many software development projects, it’s assumed that the scrum master is effectively the ‘team leader’, responsible for driving the project forward, organizing the meetings, and then actively chairing them, sticking to a rigid agenda. That can work. But the Scrum framework doesn’t require it.

According to the Scrum Guide, when it comes to sprint review meetings, “The scrum master ensures that the event takes place and that attendees understand its purpose. The scrum master teaches everyone involved to keep it within the time-box.” Nothing about leadership there, however, a scrum master has to be self-confident and strict at times, when it comes to the execution of scrum rules. But this is definitely a topic for another time.

Equally, although the Scrum Guide indicates that the product owner should take the lead on discussing the product backlog and the impact of the current increment and that the development team is there to present the increment and discuss the work of the sprint, there’s no mention of leadership there either.

You might be also interested in the article:

How to

Sprint Retrospective ideas for Scrum Masters and Agile Coaches

This should be no surprise because Scrum is not a particularly hierarchical approach. Yes, the individual roles are clear. However, the scrum team is free to decide for itself on specific questions of leadership, such as who runs a sprint review meeting?

Here at Boldare, we prefer a less leader-focused approach, with an emphasis on personal responsibility for individual tasks and collective responsibility for how we work as a team. The scrum master is there to guide, assist, and be a source of expert (Scrum) knowledge. But wherever possible, the lead is taken by the dev team, helping create a culture of commitment and delivery for the project.

We work without a dedicated project manager, ensuring our customers have direct contact with the whole development team instead, without proxies. While it may sound subversive, we celebrate this radical transparency and feel that our partners appreciate such an approach. To read their detailed opinions, visit our Clutch profile.

What are the common sprint review problems to consider?

Let’s be clear, these ‘problems’ are not really review-related, more issues with the project as a whole. However, if your sprint review is doing what it should, then as you discuss the product increment and backlog, some wider issues may emerge:

• Work is not completed during the sprint because the sprint goal was too ambitious or impractical.
• Previous sprints and decisions have left the dev team with too much technical debt.
• Insufficient time is being allocated for debugging, thus introducing problems into the code.
• Priorities are changing mid-sprint (probably via the product owner) leading to inefficient working and use of resources.

Naturally, if any of these points come up, they must be addressed before the next sprint. Though some are planning issues to be discussed in the next sprint planning session.

Sprint review meeting agenda

To help you understand better how a review meeting can unfold, here’s an exemplary sprint review meeting agenda some of our teams are using:

Attendees of sprint review:

• Scrum master;
• Product owner;
• Development team.

Sprint review agenda:

1. Check in - A few words regarding our expectations of each other. This should help us conduct a better review because we will be aware of what everyone would like to hear and/or discuss. Also, it might help if emotions were high during the previous sprint.
2. Sprint Goal discussion - Did we manage to achieve the sprint goal? And what are the consequences. This discussion is intended to provide a basis for further discussion during the review, retrospective and planning meetings.
3. Demo Session - The sprint increment is presented and stakeholders can ask questions and provide feedback - which, in turn, will be taken under consideration when inspecting the product backlog (e.g. by addressing changes in priorities or scope).
4. Sprint scope summary:

• Update regarding finished tasks - If there is something worth mentioning which wasn’t covered during the demo session.
• Update regarding unfinished tasks - Why we weren’t able to fulfill what we aimed to achieve, what kind of problems we are facing right now, how we are trying to deal with them, and decisions about next steps on these issues (abandon, reduce the scope, or continue work) and how they will impact on the next sprint.
• Comments - Clarification or seeds for discussion during the retrospective meeting.

1. Product Metrics - Update regarding product metrics, including whether have we received any feedback regarding the features we have delivered in previous sprints?
2. Process Metrics - The scrum master presents those metrics related to process and provides the team with analysis for discussion.

You might be also interested in the article:

Digital Product

Building successful apps using scrum development

Sprint review best practices

Effective sprints are as much about attitude as they are about efficient scrum processes. Consider the following sprint review best practices:

1. Bring the team together (even if not physically…) – Many, many scrum projects are carried out by distributed or remote teams. Implicit in everything we’ve said about sprint review meetings is the need for clear, honest and open communication across the whole scrum team – developers, quality assurance specialists, business analysts, the product owner, and scrum master. Maybe they’re in different cities, or countries… or time zones. Make the most of video-conferencing and other information-sharing technologies to bring everyone together in the same virtual space, if a physical space isn’t practical.
2. Focus your team culture on delivery – What is your scrum team’s motivation? Are team members focused on the delivery of a great product that completely addresses user and business needs? How do you know?

• Are the backlog and user stories well-defined and clear?
• Do you have systems and standards that actively encourage quality work?
• When you agree an increment is ‘done’, is it really or does it technically meet the team’s agreed definition of done and yet later in the project you’re finding bugs that must be dealt with, costing you time and resources?
• Culture is foundational. In a sense, a delivery-oriented team culture is more important than any single Scrum element – the team’s culture and ways of working together underpin (or not) everything else.

1. Remember to celebrate – Pretty much any project approach or methodology will tell you the importance of acknowledging and celebrating the team’s achievements – not least as a means of regularly topping up the team’s motivation reserves. In addition to the product-focused perspective, sprint review meetings are ideal opportunities to celebrate the latest iteration together and give credit where it’s due. After all, the sprint review is a chance to show off the team’s hard work.

dedicated space

New Normal in Practice

Learn how to embrace a New Normal for your organization in the post-COVID-19 era.

Explore New Normal

Sprint review checklist

For greater efficiency, it’s better when the team is fully prepared for the sprint review. Here are some sprint review tips to consider before your next (or first) meeting:

Things to consider before the review meeting:

• ‘Housekeeping’ issues – consider your practical needs: a room, equipment (including technology that brings everyone together), refreshments, maybe even catering…
• Have an idea of the structure the meeting will take; e.g. presentation of the product increment, response from the product owner (and stakeholders, if any); wider discussion by the whole team; agreement on action points… Do you need a formal agenda or not?
• Roles – what specific functions is everyone expected to fulfil (including the scrum master – see above).
• What preparation does everyone need to do? What information or understanding do they need to have in advance in order to contribute positively to the review process.

Actions to take during the sprint review:

• The product owner identifies what from the backlog has been ‘done’ or not.
• The dev team demonstrates the ‘done’ increment, answering any questions about what it is and how it works. The dev team also identifies any difficulties or pain points during the sprint.
• The product owner discusses the current state of the product backlog, including future scope.
• Everyone agrees what actions need to be taken as a result of the sprint review meeting. This action planning discussion will feed into the planning session for the next sprint.

Sprint review meeting in Agile - summary

The sprint review is the other side of the coin to the sprint planning meeting – yin and yang, not only can you not have one without the other, each needs the other (at least, if you don’t have both then your Scrum process and software development project are probably doomed to something less than success!)

A clear, structured, collective examination of what the sprint has produced, how that fits with the overall project goals, and what all that means for the next stage of the project helps keep your scrum team focused and motivated towards a shared objective, driving the project inevitably forward. With scrum tools even the most complex apps and digital products can be developed in an organized and coherent way.