Skip to main content

Sprint review meetings can be tough; in this post I'll share how to make them easier. When your team has worked hard and presents their progress, hoping for approval of items from the sprint backlog, you want to get those shippable increments approved. Let's dive into how to make it happen.

What Is A Sprint Review Meeting?

A sprint review meeting is where the product (or project) team and product owner get together at the end of a sprint to review the work that was completed from the sprint backlog.

In the sprint review meeting, the team present and demonstrate items from the sprint backlog that they think are shippable. The product owner then accepts or rejects features based on whether or not they meet the user need, acceptance criteria, DoD (definition of done), and their expectations, and then discusses with the team how to move forward.

A sprint review usually leverages Scrum software or agile project management software to help demo progress. It's usually attended by the Scrum team, Scrum master, product owner and potentially other stakeholders. It's one of the 3 Scrum ceremonies, or 'events', that characterize the agile Scrum delivery framework. They’re called ceremonies, but they’re really just meetings!

Why Run A Sprint Review?

The purpose of a sprint review is real-time collaboration between the Scrum team, product owner. and stakeholders. It's a demo of progress and results in the approval of items in the backlog to get shipped.

7 Benefits Of A Sprint Review Meeting

  1. Feedback and collaboration: Sprint reviews provide a platform for stakeholders to give feedback and allows for early detection and correction of issues. This helps in developing a higher quality product that matches user needs and expectations.
  2. Increased transparency: Sprint reviews enhance transparency in the development process. By showcasing the work done, velocity, and discussing the next steps, stakeholders get a clear view of the project progress, challenges faced, and the team's capacity.
  3. Team alignment and focus: Reviewing the sprint progress against the sprint goals helps in keeping the team aligned and focused. It clarifies expectations and priorities for subsequent sprints.
  4. Stakeholder engagement and satisfaction: Regular interaction with stakeholders during these meetings boosts their engagement and satisfaction. It gives them a sense of ownership and involvement in the development process.
  5. Adaptability and flexibility: Sprint reviews allow teams to adapt and adjust plans based on feedback and changing requirements. This flexibility is key to the success of an agile approach to handle scope uncertainty
  6. Morale and recognition: Sprint reviews offer a platform for the Scrum team to showcase their work, which can be a morale booster. Recognizing the team’s efforts and achievements in front of stakeholders can be highly motivating.
  7. Learning and improvement opportunities: Sprint reviews provide an opportunity for the team to reflect on their processes and practices, learning from both successes and challenges. This continuous learning fosters an environment of constant improvement.
Sign up for the DPM newsletter to get expert insights, tips, and other helpful content that will help you get projects across the finish line on time and under budget.

Sign up for the DPM newsletter to get expert insights, tips, and other helpful content that will help you get projects across the finish line on time and under budget.

  • Hidden
  • By submitting this form, you agree to receive our newsletter and occasional emails related to The Digital Project Manager. You can unsubscribe at any time. For more details, please review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

What Happens During A Sprint Review?

During the sprint review, the project team provides an overview of the progress that they've made during the sprint, as well as blockers or obstacles that prevented them from getting specific tasks or deliverables completed.

You can get into the how and why of any delays or blockers, but steer the team away from assigning blame or broader discussions of communication and collaboration pitfalls (you'll cover this in the sprint retrospective; see the next section).

Focus on actionable steps you and the team can take to remove blockers, get back on track, and decide on realistic deadlines for any remaining or delayed work.

Finally, the project team will demonstrate key deliverables or product features that they've completed during the sprint, and stakeholders can provide any feedback.

Prevent your sprint review meeting from devolving into a press briefing by avoiding static presentations—this format is rarely more productive than an email.

Sprint Review Vs. Sprint Retrospective

A sprint review shouldn’t be confused with a sprint retrospective (even though they’re easy to mix up!) Both are important parts of the Scrum process, and they’re the last two steps in the cycle, but the way you run them is different.

A sprint review focuses on the product, while the retrospective meeting focuses on the process itself.

Imagine you’re nearing the end of the sprint, and you have something that resembles a cleared sprint backlog.

You schedule a sprint review to check the progress your Scrum team has made toward delivery and iron out any remaining impediments.

For example, let’s say this sprint involved producing 10,000 lines of code for the app the team is working on. The sprint review meeting is the place to make sure the code is running and validated and that you’re ready to go live with it.

By contrast, the retrospective reviews the process you followed during the last sprint with the intent to improve operations during the next sprint.

During the retrospective, you collect feedback about people’s experiences integrating into the team, communicating code changes, or whatever else affected the process. 

The retrospective is intended to be a kind of debrief where everybody can learn how to work together better, regardless of the product. 

Ask people how they feel and whether they have suggestions for the next round of work on your project:

  • What would they like to see in the next sprint?
  • Do they feel like they were working under the gun?
  • Did they have too much time on their hands?

It’s still tempting to blur the lines between a sprint review and a retrospective. If you’ve put together a sprint review, you already have everybody assembled, so why not do both things at once?

The Scrum guide discourages this, and if you have to do everything in a single session, you should clearly delineate between the two phases of your meeting to prevent bleed-through.

Here’s a quick primer on which topics belong in which meetings and when to veer off and refocus the Scrum team when a retrospective threatens to break out during a sprint review.

Sprint Review or RetrospectiveWhat's IncludedWhat's Not Included
Sprint ReviewWhether the product backlog items are finished
Why the product backlog items aren’t finished
New features and functionality of the product
Delivery date of the product or a realistic release plan
How hard it was to meet the deadline
How bad people feel for missing the deadline
How it’s Julie’s fault we missed the deadline
How deadlines are a number and everybody should be more relaxed
Sprint RetrospectiveHow communication between team members has gone
Suggestions for streamlining workflow and team processes
Ways to make development teams more agile
Success criteria and methodology for developing standards for realistic milestones
Problems with the product itself
Features of the current product
Plans for technical details or a template for specific objectives

Sprint Review Preparation Tips

By implementing a system for collecting product feedback and sticking to it, you can effectively build a machine for continuous improvement and iteration.

So, how do you get started with running a sprint review? Here are some tips to keep in mind:

  • Make sure everyone on the team knows when and where the review is happening, and let everybody know what their role in the review is going to be. The more time you give them to prep, the more productive your people will be when it’s their turn to brief the team on their progress.
  • Focus on the product, and what has been built. Make the meeting a hands-on experience where the product owner and stakeholders can see and interact with the product. This approach helps in gaining valuable feedback and encourages stakeholder engagement.
  • Be thoroughly prepared, ensuring all work items are completed and demo-ready. Think through the demo and how you're going to demonstrate that the backlogged items meet the user story and the definition of done, and that they are shippable.
  • Prepare for demos by soliciting topics in advance and setting up the virtual and physical rooms accordingly.
  • Create a simple notes template to help you document meeting outcomes. Agile methodologies emphasize limited documentation, so don’t worry about getting too detailed here. It’s simply a way for you to keep track of action items related to the project.

How To Run A Sprint Review Meeting

two project managers sitting in front of a calendar for sprint review meeting
Sprint reviews are not just for demonstrating completed work. You'll also review roadblocks, progress, and what went well (and what didn't).

Although you’re free to structure sprint reviews any way you want, there are good and not-so-good approaches. Here are some steps for running sprint reviews that most people following the Scrum method have found useful:

  1. Overview of progress and setbacks
  2. Debrief of what went well and what didn’t
  3. Development of a plan to clear roadblocks
  4. Feature demonstration

1. Progress Overview

Go around the table and let everybody report how the product is going. Did they meet their sprint targets? Do the deliverables meet the user needs, user story, and definition of done?

If not, how close are they right now, and when will they be done? Don’t let the discussion sidetrack into reasons why a delay has happened. 

Focus on a straightforward reporting of progress (or lack thereof.) Discussions of why happen later, after everybody gets their reports done and you know how far along you are with the various project components.

2. Debrief

This is the part where the hows and whys of shortfalls can be discussed. Delve into this portion of the agenda after every team member has had a chance to speak, and you understand where every stage of the rollout is at the moment. 

Use the debrief to review the positive outcomes first. Note the project goals that went well, and try to assess how close things got to the deadline before they were ready. This gives you an idea of whether the tempo can go up a bit in the next sprint.

Next, look over the shortfalls, if any, and ask for input as to how the delay happened and when it will be cleared. Don’t come down too hard on the team here. If everybody effortlessly made their goals three days into a five-day sprint, it means you’re not setting big enough goals.

3. Roadblock Clearance

Anticipate what obstacles you might come across in upcoming sprints. These may be a small budget, a need for talent from someone outside your current team, a regulatory or reporting issue, or a change in market conditions that could impact product demand. 

The objective of this stage is to spot those roadblocks coming and plan to tackle them now, rather than after they cause a bottleneck in the days ahead. Use this information to update the product backlog, as needed.

4. Product Demonstration

This stage supplements your product overview with a demonstration of the key updates that shipped in the last sprint. More than anything else, it’s a chance to showcase the team’s accomplishments and foster good morale.

Sprint Review Meeting Agenda

Here’s a sample meeting agenda for your sprint review (with suggested time limits):

1. Introduction (5 minutes)

  • Brief welcome and introduction
  • Outline the purpose and objectives of the meeting

2. Review of Sprint Goals (10 minutes)

  • Recap the goals set at the beginning of the sprint
  • Highlight the main focus areas of the sprint

3. Product Demonstration (20-30 minutes)

  • Present the work completed during the sprint
  • Demonstrate new features, improvements, and bug fixes
  • Allow for brief Q&A after each demonstration

4. Product Backlog Review (10 minutes)

  • Review the current status of the product backlog
  • Discuss any items added, removed, or reprioritized during the sprint

5. Feedback Session (15-20 minutes)

  • Invite feedback from stakeholders and team members
  • Discuss what went well and what could be improved
  • Encourage open and honest discussion

6. Review of Metrics and Performance (10 minutes)

  • Discuss key performance indicators (KPIs), velocity, and other relevant metrics
  • Compare planned vs. actual progress

7. Planning Ahead (10 minutes)

  • Outline preliminary thoughts for the next sprint
  • Identify potential backlog items to be addressed
  • Discuss any adjustments based on feedback and review

8. Conclusion (5 minutes)

  • Summarize key takeaways and decisions
  • Confirm the date and objectives for the next sprint planning meeting
  • Thank everyone for their participation and contributions

9. Open Floor (Optional, 5-10 minutes)

  • Provide an opportunity for any final questions or comments
  • Address any other business or announcements

FAQs About Sprint Reviews

For convenience, we’ve compiled answers to some of the most frequently asked questions about sprint reviews.

Who Attends the Sprint Review?

Core participants in a sprint review include the Scrum master, product owner, and product manager. It might also be helpful to invite additional key stakeholders depending on your project needs (but make sure the meeting doesn’t grow so large that it becomes difficult to manage.)

How Long Should the Sprint Review Last?

The Scrum guide suggests that you should cap sprint review meetings at 2 hours if your agile team operates in two-week sprints (one hour for every week that your sprint lasts.)

IMO, 2 hours seems awfully long for any meeting. I’d recommend shortening the sprint review to 45 minutes, including 15 minutes at the end for product demonstrations. If you have a larger team, you can alternate who gives a demo week to week.

How Often Do Sprint Reviews Happen?

Sprint reviews take place at the end of each sprint, so they should occur on the same cadence as your team’s sprint cycles. If you are on a two-week sprint cycle, then you’ll hold a sprint review every two weeks.

What Happens After the Sprint Review?

Following the sprint review, your team updates the product backlog in your project management tool based on the roadblock clearance discussion and uses that information to prepare for the sprint planning meeting.

When it comes to planning the next sprint (or a project as a whole), it helps to organize the backlog in a project planning tool or a similar software tool.

What is a Sprint?

A sprint is a brief, timeboxed span in which your team works toward defined goals with the intention of having a potentially shippable product increment wrapped up at the end of it.

What's Next?

Have your own tips and tricks for running sprint review meetings? Join the conversation in Slack with 100's of other digital project managers with DPM Membership!

By Sarah M. Hoban

Sarah is a project manager and strategy consultant with 15 years of experience leading cross-functional teams to execute complex multi-million dollar projects. She excels at diagnosing, prioritizing, and solving organizational challenges and cultivating strong relationships to improve how teams do business. Sarah is passionate about productivity, leadership, building community, and her home state of New Jersey.