To-dos for your sprint reviews

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.

Location

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.

Invitations

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.

Presenters

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.

Expectations

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.

Refreshments

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.

Impediments

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!

Find out more about Sprint Reviews by taking one of our CSPO training courses.