In Scrum, the sprint review is used to showcase the work of the previous sprint in the form of potentially deliverable software. Besides the opportunity to try the software, the main goal is to receive feedback on the product: How does the product feel, and can we make it better? In a small project consisting of one team, the sprint review is relatively easy to implement. But how does it work when the product is created by multiple teams and there are a variety of stakeholders who can contribute to its improvement? In this article I want to introduce a concept for how the sprint review can be scaled.
In a current project, we're working with six Scrum teams who are developing a Web application. Each team consists of a product owner, a ScrumMaster, five to six developers, QA, and design and user experience experts. Thus a team comes to about ten people. For each team there are various stakeholders from different areas, such as marketing, category management, and so on. A sprint review can therefore easily reach a size of 60 to 80 people. We want to give all of them the opportunity to try out the current state of the product and give us feedback or make suggestions for the improvement of the product. And all of that in less than two hours!
At the beginning of the project, we had the teams present their completed stories in the sprint reviews, and we asked for feedback. The project at this time was smaller and the sprint review was attended by about 30 people. Our observation was that with such a large number of participants, people don't actively push forward and start discussions, and we usually totaled up to three to five pieces of valuable feedback. Asking questions or making suggestions during a presentation to an audience of that size is not what people tend to do. Furthermore, the participants of the sprint review didn't have the opportunity to try the developed software. Altogether, for the scale of our project, this approach turned out to be unfavorable.
After a few sprints, we thought about a new concept. We wanted more interaction with the participants of the sprint review. More feedback. More people actually using the software. The result is a concept based on a fair, and it exceeded our expectations!
We meet for every sprint review in an appropriately sized room. Each Scrum team sets up a booth in which the completed user stories from the previous sprint are presented. The user stories are presented on large whiteboards, providing detail such as graphics, flow charts, or screenshots. Each booth has several mobile computers (notebooks) available on which the software can be tested. One of the notebooks is connected to a projector so that nearby participants can follow the action. Feedback cards and pens are placed beside the notebooks.
The Sprint Review is hosted by one of the ScrumMasters. He initiates the review, in which he explains the fair and the setup briefly, and then passes on to the product owners of the respective teams. In just a few minutes, they present the motto of the previous sprint to all participants and give a brief introduction to the implemented stories. After everyone has an overview, the exhibition is opened — however, not without pointing out one of the objectives of the sprint review: Give feedback! All participants are encouraged to walk along the fair, try out the software, and leave comments and suggestions for improving the product on the feedback cards. In order to incentivize this, we announce that all feedback cards will be collected at the end of the fair and we'll celebrate with a lottery, in which one feedback card will be drawn and the winner will receive a small prize.
The fair begins. All participants move freely around the various booths. At each booth, some representatives of the respective teams act as hosts and welcome visitors. The implemented user stories are explained in detail to the visitors, who can try the software on the provided notebooks. The representatives of each team provide assistance with viewing and using each user story. Visitors are then asked to give their opinions and make suggestions for improvement. These are recorded on the feedback cards and, in a subsequent process, viewed by the product owner and possibly included as new user stories in the backlog.
After about 45 minutes, the fair is declared closed by the hosting ScrumMaster. The feedback cards are collected and the winner of the lottery is drawn.
Using this concept, we succeed in achieving the two main goals of every sprint review: New functionality can be tried out and we get valuable feedback about how to improve the product. In just over an hour. From 60 to 80 people. At the booths, practically every participant gets a chance to try the software, and we get about ten times the number of feedback cards compared to the method we used before. Not to mention that we encourage personal communication and networking among all the participants, and we create a great sense of community.