Sprint Review Meeting: Purpose, Structure, Duration

When Ken Schwaber and Jeff Sutherland developed the scrum framework, they based it on five values: commitment, focus, openness, respect, and courage.

These outstanding values are achieved through the scrum ceremonies/meetings, which include sprint planning, daily standups, sprint review, and sprint retrospective.

This article zooms in on the sprint review meeting. It covers its purpose, structure, duration, the difference between sprint review and sprint retrospective, what happens during the sprint review, and how to structure the meeting agenda.

What is a sprint review meeting?

A sprint review is a meeting held after a planned sprint is finished. It's the second step of the sprint in the scrum framework.

In this informal meeting, the scrum team (including) demonstrates what they have achieved during the sprint they just closed. That is, the team presents the new product features to determine product usability and progress toward the product goal to key stakeholders.

The scrum guide clearly mentions that this meeting should not be limited to being only a presentation and it's not a status meeting; it’s a working session.

What is the purpose of sprint review?

The sprint review meeting serves three purposes:

1. Reviewing and giving feedback on what was accomplished in the last sprint

2. Determining the changes or updates in the macro and micro environment

3. Adjusting the backlog to maximize efficiency 

The above purposes are based on the empirical scrum pillars of transparency, inspection, and
adaptation.

Transparency. Both the scrum team and key stakeholders have the same understanding of the latest product increments.

Inspection. Inspection without transparency is of no value. Progress toward agreed goals must be inspected frequently during each sprint review to detect any roadblocks. 

Adaption. Adaption is the result of good inspection. The backlog should be adjusted to prevent any deviations beyond acceptable limits or undesirable results. It is only when the people involved are self-managed that they can easily adapt after inspection.

Who attends the sprint review meeting?

Participants of the sprint review meeting include the scrum team, internal and external stakeholders, and anyone involved in the product management process.

The stakeholders are people interested in the topics covered during the meeting, such as end-users, investors, and other teams. They will check the new features and provide feedback. The sprint reviews are open to anyone, but the product owner should decide who will attend.

The product owner is the meeting leader, while the scrum master is the meeting facilitator. Different scrum team members are responsible for certain parts of presenting the work done.

How long is a sprint review meeting?

Though sprint reviews don’t have fixed time frames, the scrum master, as the meeting facilitator, should try to keep it time-boxed.

The duration of the sprint review meeting depends on how long the sprint was planned for. The general rule is that the sprint review should take no more than one hour per week of sprint duration. For example, a one-month sprint will have a four-hour sprint review, and shorter sprints will have shorter reviews.

However, the meeting facilitator can gather feedback and cover all the topics in less time by keeping things focused and helping the attendees understand the purpose of the meeting.

💡Pro tip: To have shorter and more focused sprint reviews, you'll need a meeting management platform like adam.ai. The platform is incredibly agile; you can quickly upload pre-reads, prepare your agenda with timed items in no time; quickly get back to previous meeting minutes and notes and create series meetings; create detailed action items with owners and clear deadline, and much more.

What’s the difference between a sprint review and a sprint retrospective?

Though sprint review and sprint retrospective both involve reviewing the finished sprint, the differences between both events lie in what aspect each review focuses on.

A sprint review meeting focuses on reviewing what has been done, has not been done, and work that has been added or removed from the sprint. Meanwhile, a retrospective meeting focuses on how the scrum team works together and how to improve collaboration.

Here's a quick comparison between the two.

1. Attendees

• Sprint review: Scrum team and key stakeholders
• Sprint retrospective: Scrum team only

2. Meeting goal

• Sprint review: Presenting what was achieved during the last sprint and gathering feedback
• Sprint retrospective: Improving the work processes and pinpointing what went well and what went wrong to enhance scrum team performance.

3. Meeting topics to be covered

• Sprint review:

(a) Reviewing and giving feedback on what was accomplished in the last sprint
(b) Determining the changes or updates in the micro or macro environment
(c) Adjusting the backlog to maximize efficiency 

• Sprint retrospective:

(a) What did we do well in the project?

(b) What didn't we do well in the project?

(c) How can we improve our process in future projects?

4. Output

• Sprint review: A revised product backlog
• Sprint retrospective: Listing tasks to improve workflow in the next sprint

What happens during a sprint review meeting?

In the sprint review meeting, the product owner leads the meeting by presenting what backlog items have been done and what have not. Then, the development team discusses what went well and the problems they experienced. They should also highlight what actions they took to resolve the problems.

Moreover, the development team answers the stakeholders’ questions about their product increments. Next, the product owner leads the discussion on the product backlog as it currently stands (as mentioned in the scrum guide). Based on the progress witnessed in the last sprint, he/she will be able to set projected delivery dates.

The product owner as the meeting leader also discusses changes in the economy, industry, regulations, and competition, and how they affect the product.

The main output is a revised backlog that helps the entire group establish the next steps.

What should we not do during a sprint review?

Treating the sprint review as a demo or status report

As a meeting facilitator/leader, you should frame the conversation such that the right purpose of a sprint/increment review is accomplished. You need to reframe the meeting from being only a status report or demo to an opportunity to collect feedback from key stakeholders.

The sprint review should be an opportunity for the stakeholders to sample and get a sense of the product, and then, you should help them do their best to give detailed feedback.

Not considering changes in the macro- and microenvironment

The scrum guide specifically mentions that, during a sprint review, the scrum team and stakeholders should review what has changed in the environment.

Your product exists in a complex adaptive system. Therefore, things like tremendous changes that impact the economy, changes in your industry, changes in regulations, and changes in your competition impact your product.

It's best if you brush aside the tunnel vision and expand your horizons to relate them to your product vision.

Presenting "undone" as "done"

Transparency is one of the empirical pillars of scrum. At times, developers need to present undone items to stakeholders to provide transparency during tasks of special nature. However, making a habit of presenting unfinished work at sprint review events violates the scrum values, commitment, and focus and ruins one of the most important scrum artifacts, "increment."

The scrum guide clearly states that "if a product backlog item does not meet the definition of done, it cannot be released or even presented at the sprint review; instead, it returns to the product backlog for future consideration."

So, you need to be careful about why you're presenting unfinished work. Is it because you need validation from stakeholders? If so, you need to reconsider your approach.

Canceling sprint reviews

It happens at times that the developers are lagging behind the sprint goal, and the scrum team may choose not to hold a sprint review. This can affect transparency with stakeholders.
It’s best that sprint reviews are held as usual to investigate increments and adjust the product backlog.

The team doesn’t go over the unfinished items

Many teams choose to go over the finished backlog items only and dismiss the unfinished ones. This makes sprint reviews pointless because the scrum team never addresses roadblocks that hinder them from accomplishing the sprint goal.

The developers should discuss what went well during the sprint, what problems they ran into, and how those problems were solved. This way, all stakeholders will have an idea about what is causing the delay and help find solutions, and this will count towards effective sprint retrospective meetings and provide valuable input to the next sprint planning.

Product owners don't discuss the product backlog as it stands

Product owners may not go over what’s remaining in the backlog, which can make stakeholders oblivious to what's going on and set unrealistic deadlines. To avoid this, make sure that the sprint review meeting’s main purpose is more communication, getting valuable feedback, and establishing transparency.

According to the scrum guide, this meeting should review how the marketplace or potential use of the product might have changed and review the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality and capability of the product. Based on this, the attendees can decide what is the most valuable thing to do next.

What is a sprint review meeting agenda?

A sprint review meeting agenda is a structure you follow to guide you through the meeting, and it typically includes the following.

1. Welcoming the attendees and setting the stage

The product owner is the meeting leader, so she/he starts the meeting by welcoming everyone.

Introductions are made in two cases: if participants don’t know each other and if new participants occasionally join the meeting.

It’s best if introductions are kept extremely short, just mentioning the name and the job title. If you have a large team, the stakeholders may want to know who is responsible for which task.

Afterward, the product owner can share the purpose of the meeting or ground rules, if any. It’s important to highlight that the sprint review is neither a status meeting nor only a product demonstration.

2. Reviewing the sprint goals and what the demo will include

First, the product owner should go over the planned sprint goals. Then, before diving into the demo, the product owner should make sure that all participants can easily follow what will be presented.

When product owners choose to read a list of items that will be presented in the product demo, participants may not be able to follow. Instead, he/she can present a brief overview of those items to be constantly displayed throughout the meeting.

He/she can use the following format: user story/description (planned or added); story points (size); status (done or undone); demo (yes or no).

It’s important that you mention every item that was agreed on in the sprint planning meeting whether they’re finished or not or will have a demonstration or not.

3. New features' demonstration

The purpose of this agenda item is to gather feedback from key stakeholders.

The development team or product owner should present user stories from the above list that were translated into features, mention what went well to have a shippable product increment and what problems they faced, and answer any questions related to the sprint’s increment.

4. Feedback and discussion

It's crucial to collect feedback from stakeholders both during and after the sprint review. This entails establishing a welcoming and open atmosphere for conversation. The product owner should keep a record of the feedback for decision-making.

The product owner leads the discussion on the product backlog as it currently stands (as mentioned in the scrum guide). Based on the progress witnessed in the last sprint, he/she will be able to set projected delivery dates.

The product owner should review the timeline, budget, roadblocks, and unfinished work and discuss changes in the economy, industry, regulations, and competition, and how they affect the product.

5. Updating the backlog

The main output of a sprint review event is a revised product backlog based on the feedback received.

This part of the meeting agenda starts with the product owner presenting the next set of potential sprint backlog items from the product backlog.

Then, the product owner asks for feedback on the probable backlog items to have a clear picture when deciding what to add to the next sprint.

For example, the participants may all agree that a certain feature is satisfying, so the product owner may want to accelerate everything related to this feature. Or they may give negative feedback; in such a case, the product owner may want to spend the next sprint on fixing the features that were not well received instead of moving forward with new items.

6. Closing the meeting

Finally, express gratitude to everyone for taking part in the meeting. Praise team members that excelled during the sprint and thank the entire team for their work. Announce the date and location of the following review.

💡Pro tip: Try using the meeting agenda template in an all-in-one meeting management platform like adam.ai and see for yourself how you can level up your scrum meetings.

Such a meeting management tool (i.e., sprint review tool) is second-to-none when it comes to processing and organizing all the info that sprint events entail. It connects all scrum events together and provides incredible insights for your projects. It also integrates with all the popular project management tools, like Jira and Asana.

And while there may be multiple meeting management solutions available, here is why adam.ai is the all-in-one meeting management platform you can trust:

• adam.ai is one of Atlassian Ventures' portfolio companies.
• In the meeting management software category on G2, adam.ai has been ranked a leader and a high performer for successive quarters in the past years.
• adam.ai has been included in the Forrester Report in the AI-enabled meeting technology landscape.
• adam.ai is trusted and used by powerful teams and organizations worldwide for all types of critical meetings, like board, committee, project management, and business development meetings.
• And most importantly, adam.ai integrates with your existing workflow, is SOC2 compliant, provides dedicated support and success, and has a free trial option.

FAQs

What do I review in sprint reviews?

According to scrum guide, the purpose of the sprint review event is to inspect the outcome of the Sprint and determine future adaptations, meaning that the scrum team and stakeholders work together to adjust the backlog.

Who gives feedback in a sprint review?

During the sprint review, the scrum team and stakeholders collaborate to inspect what was done in the sprint. Feed from stakeholders will help product owners have a revised backlog and a plan regarding what to do next.

What is sprint backlog?

The sprint backlog answers the why, what, and how of a planned sprint. It includes the sprint goal (why), backlog items selected for the planned sprint (what), and an actionable plan for delivering the increment (how).

What are the five scrum events that make up a sprint?

The five scrum events that make up a sprint are sprint planning, daily scrum, sprint review, sprint retrospective, and backlog refinement.

Who are the stakeholders for sprint review?

Stakeholders for sprint review can include anyone who is interested in what's covered in the meeting. This includes users, managers, other teams, and business stakeholders (investors).

What is discussed during a sprint review?

The product owner discusses done and unfinished backlog items. Then, the development team discusses what went well and the problems they experienced. Next, the product owner leads the discussion on the product backlog as it currently stands. The result is a revised product backlog.

How do you engage stakeholders in a sprint review?

To ensure stakeholder engagement in a sprint review, try to schedule the meeting mid-week instead of the last day of the week, don't make the sprint review just a demo and make it a collaborative feedback session, encourage a smooth conversation, and get them excited by mentioning what is coming up.