In my post a few months ago on scrum, I briefly talked about sprint reviews being great for getting feedback from the wider business.

Here are some tips that I’ve found useful on sprint reviews …

Getting stakeholders in the door

One of the most challenging aspects of sprint reviews is actually getting stakeholders to attend. Here’s some stuff we can do to get people in the door …

• Send a calendar invite for the sprint review a couple of weeks ahead of the sprint review meeting. The chances are that this will be a free slot for them at this point and will help avoid them booking something else in during the time slot. Make sure the invite is only for 30 minutes - it’s easier for stakeholders to justify a 30 minute meeting over a 2 hour meeting
• Send an agenda a few days before the sprint review. This serves as a reminder to the stakeholders that the meeting is happening. Make the agenda engaging by reminding the stakeholders of the business value on the new features. Reiterate that the meeting will only last 30 minutes
• Send stakeholders a sneak peak of some functionality the day before the sprint review - a screen shot of a new screen or 30 second video of a new feature. This again reminds the stakeholders of the meeting and helps engage them
• Have a verbal conversation with key stakeholders who you really want there - “are you coming? we are really excited about feature X but really need your feedback to make the feature great for our customers”

Preparing

In order to get stakeholders to come back to the next sprint review, the meeting needs to be engaging and the demos need to be slick. It needs finish within 30 minutes as well. In order to do this, the team need to prepare …

• A couple of days before the sprint review (before the agenda is sent to stakeholders), ask the team what they want to show at the sprint review. Make sure there is the right amount of content for 30 minutes
• Ask team members to think about the content of their demos and script them. Ask the product owner to feedback on the scripts - we need to make sure the content is targeted to the stakeholders and to the point
• Ask team members to practice their demos a fews times. This helps the demo in the live review run fairly smooth
• Ask team members to practice their demo in the actual environment. So, try it on the actual machine, in the actual room, on the actual projector. Very often, the screens look very different on a projector and some last minute tweeking is needed

Opening the meeting

• The product owner should open the meeting by quickly running through the agenda, highlighting the business value for features
• They should encourage the audence to ask questions and feedback during the demos
• Finally they should introduce the first demo
• This introduction shouldn’t take longer than 1 minute

Demos

• It is important to show real software because this will engage the audence the most. Powerpoint presentations / screenshots of functionality won’t engage the stateholders as much
• Encourage developers to show the features they have coded. The developers will have worked hard to make the features and as a result, hopefully, some passion for the feature will come through in the demo
• Often team members doing the demos are doing it on someone elses laptop. So, if they usually use a mouse, enourage them to bring their own mouse - it can be painful watching someone try to use a tracker pad on a laptop they have never used before
• Allow / encourage team members to remote desktop on to their own box to do the demo. This reduces the risk of something going wrong because the demo laptop is not setup correctly. Ask the team member to make sure that remote desktop access is enabled on their box though!

Capturing feedback

Getting feedback is the most important part of the meeting - it what the sprint review is all about.

• Make sure someone in the team (probably the product owner) collates the feedback
• Be positive about feedback - this is what the meeting is about. If the feedback is negative and the team don’t necessarily agree with the comments then at least say that the team will have a think about it and perhaps suggest a separate meeting with the stakeholder to drill into the feedback further
• Encourage feedback if there is silence after a demo … “what do people think?“. Pick a person out that you know is interested in the feature .. “any thoughts Bob?“. Very often people don’t feedback if the feature is spot on, so, we need to encourage people to speak up so that the team gets that validation

Closing the meeting

• Encourage offline feedback. Stakeholders may well think of feedback after the meeting or maybe didn’t want to give negative feedback in front of a room full of people
• Every so often, if there’s time, it’s worth asking the audience if they find the sprint review valuable and if there is anything they would like to change
• Finally, thank everyone for attending and make sure they know that their feedback is really useful

After the meeting

• Email the feedback back to the stakeholders after the meeting. This shows the stakeholders that we did listen and capture feedback. It also gives us a chance to make sure we have captured the feedback correctly - we may get more feedback, which is good
• Make sure any changes and bugs are logged on the backlog