Skip to main content
Methodologies & Frameworks
How To Really Run A Simple Sprint Review Meeting For Digital Projects

A sprint review is like show-and-tell from your elementary school days, but it boosts your productivity and makes you the hero of the development team. It doesn't operate on its own though. 

The technique is part of the project management Scrum framework, which is a modern way to rethink your approach to digital projects. Making your team agile keeps the costs down and improves team members' flexibility and responsiveness to the million-and-one sudden changes that come up on every project.

In this article, I'll start with a brief rundown on what a sprint review is, what Scrum is, what a sprint is, and how they work together to make you an amazing digital project manager. After that, we'll look at the role of the sprint review as one of the Scrum ceremonies (also known as Scrum events) and the ways it marks the end of one sprint before the team gets ready for the next one.

I’ll cover:

What Is a Sprint Review?

When a sprint wraps up, it's time for a working session called a sprint review. Your sprint review can be highly structured, or it can be more of an informal meeting with the team. Attendees at the sprint review include the Scrum Master, product owner, product manager, and all stakeholders.

Plan the sprint review meeting agenda well in advance to provide a structure that helps keep the meeting from falling into a mere presentation or slideshow, which the official Scrum guide specifically warns you not to let happen.

Purpose of The Sprint Review

The reason not to let your sprint review meeting devolve into a press briefing is that those kinds of presentations aren't productive and rarely have anything in them that couldn't fit into an email. 

Rather, the purpose of a sprint review is to get the team together and perform a structured review of how the project is going, what sprint goals have or haven't been met and why, and whether or not the last work period has been a successful sprint. It's basically a check-in on the sprint goal with some kind of formula for objectively measuring whether the goal of the sprint has been met.

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 will be different. The short version is that a sprint review focuses on the product, while the retrospective focuses on the process itself.

So, imagine you're about at the end of the sprint, and you have something that looks like a cleared sprint backlog. You schedule a sprint review to check the progress your Scrum team has made toward delivery and iron out any impediments still in the way of having something to deliver. 

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.

During the retrospective, you go over the process of the last sprint with the idea that the next sprint will go more smoothly. You're taking feedback about people's experiences integrating into the team, or communicating code changes, or how the new swivel chairs are really distracting because they squeak a lot, 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 what the product is. 

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, or did they have too much time on their hands? 

It's still really tempting to blur the lines between a sprint review and a retrospective. After all, if you've put together a sprint review, you already have everybody in the room right there, so why not just do both things at once? 

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

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 Retrospective?What’s IncludedWhat’s Not Included
Sprint Review
  • Whether the product backlog items are finished
  • Why the product backlog items aren't finished

  • New features and functionality of the product

  • Date the product can be delivered or a realistic release plan
  • How hard it was to meet the deadline
  • How bad people feel for missing the deadline
  • How it's really Julie's fault we missed the deadline
  • How deadlines are just a number and everybody should be more relaxed
  • Sprint Retrospective
  • How the communication between team members has gone
  • Suggestions for streamlining workflow and team processes

  • Ways to make 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
  • 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 all wrapped up at the end of it. 

    Basically, the Scrum team is pulled together (perhaps by the project manager, product owner, or Scrum Master) and considers what they'll be able to do in the next week (or however long the sprint lasts), and they agree to a set of goals they're pretty sure they can deliver. 

    Whatever work has to be done during the sprint is called the product backlog, and what counts as clearing it will be defined in writing beforehand. This is part of the sprint planning session, which happens directly before the sprint itself.

    You can write this set of product goals on a whiteboard under something imposing and vaguely wise-sounding, like ‘definition of done,’ so everybody knows where the finish line is for this week's sprint. 

    What Is Scrum?

    Scrum is a methodology that is focused on getting a team’s work done in small chunks at a time, in increments and iteratively. The purpose of scrum is to help everybody on the team learn through each others' experiences, develop the ability to self-organize, and, hopefully, keep everybody motivated with a structured examination of the team's successes and shortfalls during the sprint period. 

    Scrum is made up of the five ceremonies I alluded to earlier, which are:

    1. Backlog grooming
    2. Sprint planning 
    3. Daily scrum (aka daily standup, or daily scrum meeting)
    4. Sprint review
    5. Sprint retrospective

    Why Run a Sprint Review?

    A sprint review introduces consistency and reliability into digital project management. By adopting a process and sticking to it, you can effectively build a machine for continuous improvement. 

    The nice thing about building a formal review process into your production cycle is how it adds a review and feedback system to the normal development and rollout plan you're already following. So, how do you do it?

    How To Run a Sprint Review for Digital Projects

    Obviously, you're free to structure your reviews any way you want, but there are definitely good and not-so-good ways of doing it. Over time, a process has developed that most people following the Scrum method have found useful. 

    Briefly, the steps to a proper sprint review are:

    1. Scrum team check-in
    2. Overview of progress and setbacks
    3. Debrief of what went well and what didn't
    4. Discussion of completed items and backlog clearance
    5. Development of a plan to clear roadblocks
    6. Energy check and prep for the next sprint

    1. Check-In

    The first step to a successful meeting is, well, meeting. Start your review by making 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 can give them to prep, the more productive your people will be when it's their turn to brief the team on their progress.

    2. Progress Overview

    Go around the table and let everybody report how the product is going. Did they meet their sprint targets? If not, how close are they right now, and when will they be done? Don't let the discussion sidetrack here into reasons why a delay has happened. 

    Focus on a straightforward reporting of actual progress or lack thereof. Discussions of why happen next, after everybody gets their reports done and you know how far along the various bits of the project are.

    3. Debrief

    This is the part where the hows and whys of shortfalls can be discussed. Start after every member of the team has had a chance to talk and you know where every stage of the rollout is sitting 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 all their goals three days into a five-day sprint, it means you're not setting big enough goals. Ideally, somebody on the team will always arrive at the review just half a day or so behind schedule.

    4. Clearance Discussion

    This stage comes after you go over what went right and wrong, and more than anything else, it's a chance to really go into depth about why things turned out the way they did. Schedule some Q&A for the stakeholders, and walk them through all the updates and releases you have pending. 

    If you're rolling out a new message app, for example, and the sprint that you are reviewing was focused on the UI and UX, keep everybody on the topic of the user interface and the various functions of the program rather than on design issues or content creation. If you're not careful with the topic control here, the questions are likely to spiral off.

    5. 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 anything. The thrust 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.

    6. Energy Check

    Whew! Everybody's tired and ready to go home now. Not so fast. A frequently overlooked purpose of the review is to let people wind down after a glut of work and get stoked about the next sprint.

    The end of the review should always be positive, and it should leave everybody feeling charged up with the energy to tackle the next stage of your development. 

    Plan Your Next Success

    Planning and executing a successful Scrum cycle takes a lot out of digital project managers, but it's worth it when you see the rewards. Now that you're a hero for boosting production by, let's go with 300%, it's time to plan your next success. The Digital Project Manager is way ahead of you on this one.

    We have a great newsletter you can get for free that will keep you up to speed on all the latest in digital projects, management techniques, and team management strategies to keep you ahead of the curve. Sign up for it now, and we'll bring the donuts for your next sprint review meeting.

    By Galen Low

    I am a digital project management nerd, a cultivator of highly collaborative teams, and an impulsive sharer of knowledge. For the past decade, I've been shaping and delivering human-centered digital transformation initiatives in government, healthcare, transit, and retail. I'm also the co-founder of The Digital Project Manager and host of The DPM Podcast.

    Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.

    [class^="wpforms-"]
    [class^="wpforms-"]