Retrospectives and Reviews

To-dos for your sprint reviews

Posted by Ilan on January 30, 2012
I'm Ilan Goldstein and I'm a director here at AxisAgile. I'm a Certified Scrum Trainer and the author of Scrum Shortcuts Without Cutting Corners. Find out more about me or get in contact with me by using the social buttons. I also respond to comments below.

WARNING: On the surface, this Scrum activity appears to be both simple and straightforward. But be warned: without careful preparation, this session can lead to riotous table-thumping and streams of tears.

Just show the stakeholders what was completed over the last 2-week sprint — sounds simple right? Well, based on my experience, a sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate.

The core issue is aligning the expectations of a disparate group of stakeholders outside of the team. These people are often more senior in the business relative to the team, they most certainly have less familiarity with the project compared to the team, and without wishing to generalize, they often have the attention span of a puppy with an attention-deficit disorder!

During Sprint Planning

Preparation for the sprint review actually starts during the previous sprint planning (see Figure 1). During the planning session, the team must ensure that tasks are being allocated appropriately in readiness for the sprint review. These tasks include:

  • Preparing some basic demo data
  • Preparing a demo workflow script
  • Ensuring the demo environment is working as expected

You don’t want the team to spend too much time on these tasks, as the sprint review shouldn’t be turned into a dog-and-pony show, but these tasks certainly need to be acknowledged.

There are also a few important points to stress to the team during sprint planning. First, the sprint review demo needs to be conducted on the staging environment rather than on the development server (and definitely not on an individual’s machine). This is not a smoke-and-mirrors demonstration, and the team needs to really prove that what it has developed is releasable.

Second, although the team should feel relaxed during this session, it still needs to be taken seriously. During the sprint review, the efficacy of both the team and Scrum is on display to those who might not have had much exposure to either.

During the Sprint

Once into the sprint, the ScrumMaster and product owner need to start running through their collective checklist in anticipation of the review (see Figure 2). Items to cover off include location, invitations, painful attendees, presenters, and expectations.


Confirm the location of the sprint review. Make sure that any relevant meeting rooms have been booked and that they are well equipped for the occasion. Double-check that a suitable projector, ample seating, network connectivity and a whiteboard are available. I also recommend testing that the equipment works as expected; nothing is more embarrassing than so-called technology experts unable to get the projector to work before the session even begins.

During the sprint, the ScrumMaster and product owner should go through their collective checklist in anticipation of the review.


Ensure that invitations are sent to the relevant stakeholders as early as possible. In fact, there should be a standing invite to the regular attendees, so this suggestion applies only to any anomalous extras.

Painful Attendees

You may have concerns about a particular stakeholder who has a habit of taking center stage and issuing unwarranted criticism or off-tangent comments. If you have one of these delightful characters to deal with, I recommend that the ScrumMaster and/or product owner visit him or her before the sprint review to present a sneak peak and to get some early input. People who feel a little bit special are less likely to be destructive during the review. We don’t want to fix the results, but we certainly want to avoid unnecessary morale-busting reviews.


Near the end of the sprint when you are able to ascertain exactly which user stories will likely be demonstrated, ensure that the team has decided who will be demonstrating what. It might be just one individual, or it could be a group effort—there is no hard and fast rule.


Once the demonstrable stories have been determined, I recommend circulating an email to all attendees to give them a brief heads-up of what is going to be presented. The reason for doing so is that in the early sprint reviews of a project, the user-ready features with a snazzy UI are typically few and far between, which can lead to some miffed, eyebrow-raising stakeholders. For example, by informing them that the upcoming sprint review focuses primarily on the less visual, technical “plumbing,” there is less likelihood of misaligning expectations.

This email also serves as a friendly reminder of when and where the session is with a gentle warning that any latecomers will have to supply coffee!

During the Sprint Review

When it comes time to conduct the actual sprint review (see Figure 8.3), consider the following tips to help ensure a smooth ride.


Everyone loves snacks. Ensure that there is something to nibble on as well as drinks (hard whiskey if you’re really worried about how the review will go). I find it amusing that people’s positive or negative judgment of a conference or training session often comes down to the catering, so don’t forget to look after everyone’s stomachs!

Scene Setting

Once everyone has settled in and engaged in some light banter over the refreshments, the product owner should briefly outline the sprint goal as well as reiterate what will be demonstrated. Also, for early sprints, it doesn’t hurt to explain the definition of done to the stakeholders.


Following the scene setting, it can also be a good idea to discuss any impediments that impacted the sprint, including why they occurred and how they were dealt with. This is an opportunity to lobby for greater assistance if there are any systemic impediments. An example might be the physical environment—perhaps a problem dealing with the facilities department in your mission to get larger desks or more breakout space.

In addition, I recommend using this segment to briefly make a point of key process improvements that were implemented to help achieve the sprint goal. Don’t go into detail here, as this session is about reviewing the product, but a quick mention won’t hurt and is a great opportunity to demonstrate to the stakeholders that the team is constantly improving.

The Main Event

Instead of a one-way showcase, the demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team. It should be an open and honest discussion focusing on what was completed and what is coming up next.

Remember that this session should not become a smoke-and-mirrors slide show presentation to impress the attending stakeholders (unless, of course, your team is actually developing PowerPoint or Keynote!). I assure you that misleading demonstrations will only come back to bite the team.

Preview at the Review

It is a fundamental tenet that during the sprint review, the team should demonstrate only stories that meet the definition of done. It makes sense, but it can be very frustrating for some stakeholders, and the reality is that the team will possibly receive pressure to still show what has been worked on (even if it is not quite finished).

In this situation, instead of being a stubborn mule, I recommend creating an additional agenda item labeled “Coming Soon.” This way, much like a movie preview, there is acknowledgment that the work isn’t complete, yet the stakeholders still get a sense of work that’s on the boiler and is coming soon to a sprint review near you!

Breaks and Phones

If your session is longer than an hour, I suggest taking 5-minute breaks every 45 minutes to maintain focus. But, be aware of the attention-deficit-disordered puppies who will get easily sidetracked and mugged in the corridors: don’t let them stray far.

Also, although tough to enforce, try requesting that everyone submit their BlackBerrys (providing that RIM is still around when this is published) at the door. The only problem is that you may need to hire armed guards to pry those smartphones out of stakeholders’ hands! At the very least, you should announce at the start of the meeting, “For the safety of this sprint review, we request that you turn off all electrical devices.” Good luck and at the very least, think up a creative punishment for those whose phones ring during the session.

So-Called Suggestions

There will no doubt be a range of questions and suggestions that surface throughout the session. I recommend that questions be controlled and kept on topic. The team should answer any and all questions that surface in relation to what is being demonstrated; however, questions that are tangential or completely off topic should be taken “offline” by the product owner and discussed with the relevant stakeholder(s) in a separate meeting.

Acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down on the whiteboard or index cards. With any luck, after seeing any crazy suggestions written in black and white, stakeholders will retract their pearls of wisdom. Any reasonable suggestions should of course be added to the product backlog (by the product owner) for further assessment and consideration.

Picnics or Battles

Sprint reviews can be akin to turning up for a summer picnic or, alternatively, turning up for pitched battle! It comes down to taking the necessary precautions and treating each session seriously while still having some fun. Don’t assume that every stakeholder has the same level of background as the team, and ensure that all attendees are made to feel comfortable by always explaining what is happening and why.

Aligning everyone’s expectations is the name of the game, and achieving this objective is critical if you prefer picnics to battles!

If you liked this article, you can:
Subscribe to this RSS feed!

  • Eek, it’s hard to picture an hour-long sprint review. We try to keep ours to 15 minutes, and no longer than 30 (after all, we release every two weeks so that’s a big investment of time from everyone in the company).

    I do like the idea of snacks, although we don’t provide those for sprint reviews. I’d like to share a few of the sprint review ideas we’ve developed over 8+ years of doing sprint reviews.

    We have a page on our company wiki for each sprint that lists all the stories, tasks, bug fixes and database changes for that sprint. For each story, we link off to a wiki page for that particular story. But, where appropriate, we also include links to screenshots that illustrate the user story. We find this helpful when we go back months later to try to remember what we did in a given user story. We also often use these screenshots in place of demo-ing the actual page “live”. Heresy! I know! But, navigating to every page needed in a sprint review takes valuable time. If the only thing that changed was a report, or static text on a page, nobody really needs to see that real-time.

    We’re also attuned to how many stakeholders there actually are for each story. If we do a user story that only the accountants care about, we make sure to show them in advance, and don’t spend a ton of time on that story in the meeting. For that matter, we demo early and often on every story, so the sprint review is usually just for the people not directly involved to get an idea of what’s about to be released.

    Since we keep our meetings short, we don’t have to check blackberries at the door. One thing we’ve learned to do is, after talking about each user story, we ask if anyone has any questions, and make sure everyone has understood.

    At the end of the sprint review, we go over our stories for the upcoming sprint. This is sometimes a chance to get a bit of input to those stories, or at least make people aware they might want to come get their two cents’ worth in later.

    I just lived that projector dilemma at last Friday’s sprint review. Thanks for all the good advice and tips!

    • @Lisa – thank you for sharing your experiences. I think that your “screenshot” example is practical and perfectly fine so there will be no burning at the stake this time 🙂
      Really cool that you are able to consistently keep your reviews so short! It would be interesting to know how big your typical team is.
      Also, I recommend that for any readers who have not yet read Lisa’s (and Janet’s) fantastic, seminal work on Agile testing, that you pick up a copy asap!

  • Sanjay Sharma

    Ilan, I agree to your point that somestimes stakeholders want to see work that has not finished but I find that in my situation, it is the team who are wanting to show or talk about the work that they have in the pipesline but not met ‘definition of done’. It is they who are keen to talk about and want to show features that have not been done.

    Having your idea of a coming soon section allows them to talk about the work they have nearly finished and also gets the stakeholders wanting to come back to the next review meeting, especially if it is functionality that they are wanting to see.

    Nice article.

    • Thanks Sanjay – indeed holding off on presenting this work is tough but I see no issue in a dedicated section for this so long as you explicitly recognize the fact that it is incomplete.

  • ScrumGirl

    Great article, Ilan. It took my team a long time to get to a stage where our reviews weren’t being disrupted by environment problems, tangential conversations / debates, and muck ups due to inadequate planning. However we pretty much did most of the things you mentioned here to fix it! One other thing we do is make the demonstration of a story part of the peer review process during the sprint. The reviewer can’t approve any work until the developer runs through how they propose to demonstrate the functionality they just implemented at the owners’ review. I find these “mini” dry runs work a treat 🙂

    • Thanks ScrumGirl – I absolutely agree with your comments regarding the intra-sprint walkthrough demo and in fact, you will see a whole article on the topic coming soon…

    • > The reviewer can’t approve any work until the developer runs through how they propose to demonstrate the functionality they just implemented at the owners’ review. I find these “mini” dry runs work a treat 🙂

      Excellent suggestion ScrumGirl!

  • IIan,

    Another great post. Having said that, I’d like to see you add a couple more “TO DO’s” that are supposed to occur in a Sprint Review:

    Product Owner:
    * discusses current snapshot of Product Backlog
    * projects likely completion dates with various completion rate(or velocity) assumptions

    All attendees then discuss previous agenda items(completion dates, current snapshot of PB) and how they affect what to do next
    * Provides vital input into the impending Sprint Planning Meeting

    I would post another link to my article talking about this stuff but I don’t want you to get the impression that I’m trying to advertise my blog on your blog! I’m a big fan of your blog!

    • Hi Charles – thanks and I like your additions 🙂 Also, you are obviously not a spammer and I really like your blog so feel free to provide links where applicable and topical – the goal is to help the readers as much as possible so the more valuable content the better 🙂

      • You’re welcome. I’m beginning to think it would be really nice if they would describe the Sprint review in two parts much like they do with the Sprint Planning Meeting. Most people for get about the 2nd part.

        You could do:
        The what? (What is done?)
        The how? (How are we progressing towards our goals? AND How do we incorporate the review feedback and progress info into the backlog for the upcoming sprint?)

        You could extend the what/how metaphor to the Retro too…
        The what? (What do we want to change?)
        The how? (How do we make that change happen?)

        Or you could go totally different and just say the review breaks into:
        Part 1: Demo and Feedback
        Part 2: Goal Progress and Backlog tweaking

        Anyway, it just bothers me that people forget the 2nd part of these two events, because I think there is as much value and maybe more in the 2nd part.

        • Hi Charles – indeed this sounds like a natural progression that hopefully becomes a de facto standard.

  • Pingback: Scrum Sprint Reviews Checklist()

  • pamela

    This has been very insightful. We are struggling to get attendees. Both our internal stakeholders (company staff) and external stakeholders (clients) have not really bought into the idea of Sprint Review.
    Are there any suggestions for metrics that can be used to gauge the success of Sprint Review?

Sign up to receive our eNewsletter



Send this to friend