In an agile context, the sprint (or iteration) lifecycle is punctuated with following meetings:

• The sprint planning, the kick-off meeting to specify the sprint functional scope;

• The daily scrum, where every team member answers three questions
• what I did yesterday ?
  
• what will I do today ?
  
• did I meet some troubles ?
  

• The sprint review, that we will address in the current post;

• The retrospective, to review the timeline, what went well, what could be improved and specify action plans from the past sprint.

We recommend you to read Scrum and XP from the trenches, written by Henrik Kniberg, for an extensive presentation of these meetings.

In this post, we will focus on sprint review in a particular context that we know well: stakeholders are noticeably distant from the team. We will present the review goal, will list contributors and their roles and how to manage distance in the best way.

The sprint review goal

Once the sprint is finished, the team proceeds to the demo of the product about to be delivered. Thanks to that review, the team collects a direct feedback on developed features. Besides that feedback, this meeting is also a way to imply the development team and to confront her with the client expectations.

The sprint review has other benefits. On this occasion, the team can have some ‘job done’ reward. It is also a way to open the team to outside persons: firm employees that do not participate to the project can assist to the demo, discover what have been done, share knowledge and give their feedback.

The contributors and their roles during the review

Everyone is invited !

• The development team: they are here to present the product. They prepared the demo script, and every team member has the occasion to present one or several features;

  
  

• The Scrum Master ensures that user’s feedback is precisely collected. She can also make her remarks about the product;

• The Product Owner launches the meeting introducing the sprint goal, lists the finished user stories, notes every remark or correction, and of course validates (or not) the user stories;

• The users and project sponsor are there to make their remarks, their correction and feature requests. The demo is the dedicated event to collect some of the user needs.

A particular context: Manage the distance with the stakeholders

For an application we developed, we were on the following situation: users’ representatives were for the first one in the United States and for the other one in Germany. As we absolutely want to perform the demo, what do we do?

There are two options:

• To go to the stakeholders or making them come to us. That is not always possible and could be expensive. And the carbon tax would be dangerously growing
  

• Setting a remote sprint review.

You catched us, we use second option to maintain this Scrum meeting. Tha requires to set a conference call and to use a web meeting tool to allow the users’ representative to follow the demo from their own computer. Lastly, we chose Cisco WebEx that is very efficient. The web meeting organization is simple and quick, and the rendering is sufficiently fluid for attendees.

Concretely, a single computer is used to perform the demo. From this computer, the meeting is initiated, client attendees are invited by mail. Once every attendee has joined the virtual meeting room, the screen is shared and the demo can begin. Team members are succeeding each other and everyone can demonstrate new features. In such case, the demo preparation is very important. Be careful to properly take into account the language barrier: team members must take their time and have prepared every speech. Such a demo is free of little details: we must select the behaviours to show, to concentrate on what is really important to present.

For the rest, that is the same as a ‘classic’ demo: team members presents their features, behaviours, users ask questions and make some feedback.

Conclusion

The sprint review allows to see how the product moves forward, to collect a direct feedback from the stakeholders, to imply and gather people regularly. Of course, distance can not justify not to do it. This meeting is necessary for several reasons: clients know exactly how the product evolve as they see it, the can change behaviours. After that meeting, the Product Owner is able to modify her backlog adding, removing or updating user stories, or manage her priorities. With the existing web meeting tools, it won’t be not be a reasonable choice not to perform the demo!