What is a Sprint Review?

Participants of the Sprint Review

The Sprint Review is attended by the entire Scrum team – the developers, the Scrum Master and the Product Owner – and ideally also stakeholders – such as users, managers, representatives from areas such as marketing, sales and IT. Of course, the Sprint Review does not address all stakeholders; competitors are also affected by the results, but they will not want to contribute to improving a competitor’s product. In practice, the focus of the meeting is primarily on the exchange between developers and the product owner as the representative of the stakeholders. If the Product Owner cannot cover all technical aspects, the client should participate in the Sprint Review or send an appropriate substitute. If this is not possible, the acceptance of corresponding user stories will be postponed. In the case of complex stories, the client should already be involved before the actual review, otherwise the acceptance could become too extensive and fail.

Sprint Review as Scrum Event

Scrum defines different events, which are executed once or several times. In addition to the Sprint Review, this includes the Sprint Planning, the Sprint, the Daily Scrum and the Retrospective. The Backlog Refinement is also carried out as a continuous task; however it is not explicitly a Scrum event.

Just the number of events – sometimes referred to as rituals, ceremonies or meetings – reveals the importance of communication in an agile context. No event is more important than another, because each pursues its own goals and a concrete meaning. The purpose of the Sprint Review is the feedback of the stakeholders – opinions, criticism, praise and suggestions for improvement – which flows into the further development.

Procedure of a Sprint Review

After a short greeting – an unfreezing is unnecessary in itself and goes against the agreed timebox – by the Product Owner and a short introduction of the participants, if they do not know each other, the explanation of the rules follows. A golden rule like the one in the Sprint Retrospective is especially useful.

Before the team starts presenting the completed user stories, the Product Owner should present and, if necessary, distribute a list showing which items have been implemented and demonstrated and which have not. This list should be agreed in advance between the product owner and the development team, because it also determines the later presentation sequence of the implemented items. In some organisations, this list is already sent out with the invitation to the Sprint Review, because this makes it easier for visitors from marketing or sales to decide whether it makes sense for them to participate.

The heart of the Sprint Review is the presentation of the new functionality, ideally by the developers themselves. This is where the feedback of the participants is asked for and the user stories are at best accepted, but if necessary not accepted. Before a discussion about the upcoming backlog items takes place, the Scrum Master can explain the biggest challenges of the sprint. In most cases, these points relate more to the process than to the implementation of the requirements. The Sprint Review should end with thanks to the developers and presenters and the date for the next Sprint Review.

Regular Presentation of Results

There are good reasons why features of a software are presented in real time before the software is fully developed. Even if there are managers who don’t want to invest much time in such presentations, in the long run it is the only way to take a look at the progress of a development. Progress messages sent by e-mail or information between doors can work, but it is much more likely that results will be produced in the end that are surprising for one or the other responsible person. The regular presentation of the results gives management and other important stakeholders the opportunity to gain their own impressions, identify undesirable developments, give feedback or express wishes and ideas.

The Sprint Review offers an excellent way of controlling, it is a kind of development and project controlling in real time. Statements like “We are on schedule” can now be checked by yourself – all that is needed is an investment of 4 hours or less once a month. In addition, stakeholder participation also transports a message to the developers: “We are interested in your work and your results”. The alternative could be perceived as ignorance and even lead to demotivation.

Timeboxing in the Sprint Review

Communication and feedback is very important in Scrum. To ensure that this communication takes place in an orderly manner and does not involve too much effort in the various meetings, it is advisable to use a timebox. The Scrum Guide recommends a timebox of 4 hours or less for a review for one-month sprints, 3 hours or less for a three-week sprint, etc.

In order to keep the agreed timebox, it is necessary to communicate in a meaningful and structured way. It makes a lot of sense to describe the process to all participants at the beginning of the review, even if most or even all participants have participated in Sprint Reviews before. The explanation of the sprint goal, the consideration of the progress towards the product goal and the naming of the timebox provide the participants with additional points of orientation.

If the client takes part in the meeting, there can be extensive discussions about the intention of requirements and the design of new features. Here too, it is important to keep an eye on the timebox. Possibly separate meetings with a smaller number of participants make more sense and reduce the effort.

Advantages of a Sprint Review

Performing a sprint review at the end of a sprint has several advantages:

• The Sprint Review reveals what has already been worked out. Since only realised user stories and their implementation can be presented live in the product, the progress of the development is directly visible for all participants.
• There is direct feedback between the developers and the stakeholders and thus criticism, praise or suggestions for improvement. These can be planned by the product owner for the next sprint.
• Stakeholders receive lively information about the development instead of anonymous reports. This makes it much easier to deal with the results.
• The preparation effort for developers is low, because only finished solutions are presented. PowerPoint presentations or similar media should be avoided in reviews.
• The team’s identification with its own work results increases.
• Ideas for further functionalities can be developed together.

Tips and Tricks for the Sprint Review

There are a number of tips and tricks that can contribute to the success of a Sprint Review:

• The number of participants can become very large, therefore a good moderation, clear rules and procedures, as well as the consistent alignment to the agreed timebox are very important.
• Usually the Product Owner is also the moderator of the Scrum event. So he has two hats on, which he has to separate in any case. Of course, he may give feedback, but he should be reserved, for example, when planning new user stories directly due to the feedback provided.
• The participation of important stakeholders is essential, because their feedback clearly verifies the actual value of the implementation.
• Low presentation skills of the developers can lead to a lack of acceptance among stakeholders. Here a conscious decision should be made whether an internal rule – the feature is presented by the developer who implemented it – should be retained or, in a particular case, handled alternatively
• The release of implemented user stories is important, but feedback is much more important. The feedback results in the approvals. If the Sprint Review becomes a pure release event, the actual meaning is missed.

Why is it that Sprint Reviews are often understood in practice as Inspect & Accept rather than Inspect & Adapt?

Notes:

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Here you will find an experience report on the implementation of a Sprint Review in Large-Scale Scrum (LeSS).

Here you can find 4 big ideas to improve sprint reviews.

And here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.