Get More out of Your Sprint Review

Is your Sprint Review just a dog-and-pony show for your stakeholders?  If so, then you may be missing one of the most valuable aspects of the Scrum process.

It’s Not a Demo, It’s a Review

The root of this problem often lies in the habit of referring to the Sprint Review as a “demo”.

Demos are one-sided meetings where the team walks through the highlights of the product in a carefully scripted manner to a disinterested set of observers.

Reviews, on the other hand, are hands-on conversations between the team and stakeholders to discuss the work they’ve done so far and how it matches the stakeholder’s intent.

A good review lets stakeholders test drive the work the team has done so far in as close to a real-world environment as possible.

Only then will the team get the feedback it needs to adapt their plan moving forward to deliver a great product.

So, how do you ensure that you’re making the most of this opportunity?

Here are a few tricks to help you out…

Get the Right Feedback

Believe it or not, many stakeholders are just as uncomfortable in their first review as the team is.Some may worry about hurting the team’s feelings after a strong effort, or looking silly when they offer their opinion to the team they’ve hired to be the “experts”.As the facilitator of the review it’s your job to put them at ease when offering their feedback and to help them understand what types of feedback would be the most helpful to you.

First, let the stakeholders know that the entire purpose of this session is to get their feedback so they should not hesitate to give it.

Without their feedback, after all, you won’t know when you need to adjust course.

Second, coach them on the specific types of feedback that would be most helpful.  The type may change depending on the product that you’re building, but some common examples include…

• Flow – Does the way the user moves through the app make sense?
  Is there a better way?

• Messaging – Is the language the team is using in the app appropriate to the product.  This can be particularly important in products that target a specific business domain, such as healthcare, to ensure that users understand the features as quickly as possible.

• Superfluousness – Is everything that the team is showing useful and providing value?  Is there anything that could be removed?

Giving stakeholders examples of the specific types of feedback that you're looking for often makes them more likely to offer it during the session.

And although stakeholders tend to start with the specific types that you prompt them with they'll rarely constrain themselves to it for long.

Finally, be sure to elicit this feedback in an open ended manner instead of asking them as yes/no questions.

For example, rather than asking if the messaging that you’re using in the app is appropriate, ask if there’s more appropriate message that could be used instead.

Or, if you are seeking more general feedback for a portion of the app, do not simply accept “yes, this looks good”.Continue digging until you understand why the work looks good and why it is solving the problem at hand so you can replicate that same experience elsewhere in the app.

Plan Ahead

Although we want Sprint Reviews to be a two way conversation rather than a scripted demo that doesn’t mean that we don’t start with a little bit of planning.Make a list of the key topics you want to get feedback on before the Sprint Review.

These may be new features that have been added to the product, significant enhancements, or particularly nasty bugs that were fixed.

Like Scrum ceremonies, the Sprint Review is a time-boxed meeting so be sure to prioritize the list to tackle the most important topics first.

Once the list is complete, send it to attendees before the review to encourage the right people to attend.

Although a large meeting may be more difficult for you to manage, sharing the topics ahead of time will increase the chances of getting the right people in the room to get the feedback that you need.

As a word of warning, though, be aware that your list of topics does not evolve into a script.

Carefully scripted Sprint Reviews yield little value since they don’t accurately represent the product in use.

Interact with your product casually in the Sprint Review just as you would in a day to day scenario.

This will best convey the actual working state to your stakeholders and will invite their feedback if it doesn’t.

A demonstrable more casual approach to your interaction will also convey to them that their feedback is invited at any time, while a scripted Sprint Review will appear more formal and encourage attendees to hold their feedback until the end of your presentation.  Instead, keep the review casual and informal.

After all, your users won’t be using the product from a script…why should you?

Use Real Data

Just as we ant to interact with the product in a meaningful we'll want to do so using real data.

All too often we prime products with carefully scrubbed test data that’s been painstakingly curated to contain elements that we’re certain the product can handle.

Unless your users are also painstakingly scrubbing any input or data they feed into your product this gives an inaccurate representation of the state of your product to your stakeholders.

Strive to conduct every Sprint Review with as authentic test data as you have available and use each review to re-confirm with your stakeholders that the data you are showing is representative of the actual data they will be working with.  Unless you explicitly call it out, many stakeholders will assume that you're aware that your data is not indicative of what the product will be working with in the real world...encourage them to call this out so you can get the test data you need.

Coming Attractions

A common question for new teams embarking on their first review is whether or not they should review unfinished work.

Although, not everything the team creates is worth reviewing along the way, if it’s a significant portion of the product then you should take the opportunity to put it in front of stakeholders as soon as possible.

This “first look” is your chance to confirm that you haven’t completely misunderstood the overarching goal of the feature before you get too far down the wrong path.

Reviewing unfinished work can be a bit tricky, however, especially with stakeholders who are new to an agile process.

If you do decide to review unfinished work be sure to add the caveat that this work is still in progress and that you’re most interested in feedback concerning whether the team has correctly understood the problem and if they're on the right track with the solution.

As with other pieces of the review, coaching stakeholders on the type of feedback that is most useful here is critical.

It can be helpful to save these topics until the end of the session.

As this work is still new it tends to be the most malleable, therefore it’s of lower priority than work that's nearer completion.

Also, since less completed work tends to invite more open-ended feedback the natural time box of the Sprint Review can help manage this feedback before it grows out of control.

Inspecting and Adapting

Sprint Reviews are one of the most important ceremonies of the Scrum process as they allow teams to get to the critical feedback that results in a great product.

Without genuine feedback, the team has nothing to adapt to and runs the risk of continuing down the wrong path without an opportunity for correction.

It’s the team’s responsibility to make the review as authentic and productive as possible so they can get the right feedback from their stakeholders and deliver the right product, in return.