Theory "Sprint Review"

Review of the Increments of this Sprint¶

After the Sprinting is completed, the Sprint Review takes place. As you already know from the previous chapters, this is an official Scrum Event. The purpose of the Sprint Review is to check the results of the Sprint and to determine future adjustments. Here the acceptance of the Increments takes place, it is checked whether the Sprint Goal has been achieved and the progress towards the Product Goal is discussed.

Prior to the Sprint Review¶

The Scrum Master is responsible for planning and conducting the Sprint Review Meeting. As part of this, he invites the Product Owner and anyone else who is interested in attending the Sprint Review. The Product Owner has to attend the Sprint Review, but the other invitees often decide for themselves whether they want to participate in the Sprint Review. They make the decision dependent on whether topics of interest to them are discussed in the Sprint Review or not. It therefore makes sense to send out a list of all the User Stories that have been completed and will be presented in advance. This way, the stakeholders can better decide whether they consider it useful to participate in the Sprint Review or not.

Live demo, not a simple presentation¶

In this meeting, the Developers present the results of the current Sprint to the stakeholders. Like the Daily Scrum Meeting, the Sprint Review Meeting is neither a status meeting nor a reporting session! There is no explicit reporting in Scrum. Since the latest Increment is presented to the stakeholders and the Product Owner in the Sprint Review, it can be said that the Sprint Review replaces reporting in the broadest sense.

The presentation of the Increment is not done through a PowerPoint presentation or similar. The Increment, which is potentially deliverable, is presented and tested as such in a live demo. The presentation is therefore not theoretical, but practical. Questions about the Increment are explicitly welcome.

For this reason, the Sprint Review can be held in a variety of rooms. For example, it makes sense to hold the Sprint Review in a laboratory if the development work has also taken place in a laboratory. If the Developers mainly worked in a certain office, they could also meet in this office for the Sprint Review.

As the Developers present the Increment to those attending, all Developers should have basic presentation skills. A poor presentation of the Increment can lead to stakeholders not being satisfied with the results - so make sure that the demonstration does not fail because of the way it is presented.

Testing and clear feedback¶

The Product Owner is encouraged to test the Increment. Acceptance tests are used to show the customer that the Increment is usable and what tasks the Developers still have to do. It is important that the Product Owner actively participates in the Sprint Review, because the Developers require the feedback in order to continuously improve in the forthcoming Sprints. Both praise and criticism are important here. But not only the Product Owner is allowed to give feedback: The other stakeholders are also invited to give constructive feedback. The more feedback the Developers receive during the Sprint Review, the better it is. The advantage of feedback during the Sprint Review is that it reaches the Developers without intermediate stages. They hear directly from the person testing and from the stakeholders what is good and what is not that good about the Increment. Minutes should be kept of this feedback so that the results of the meeting are also recorded in written form.

Acceptance criteria¶

In the chapter User Stories, Epics, Product Backlog Items you learned that acceptance criteria must be defined and recorded so that the corresponding user story can be accepted.

The acceptance criteria defined beforehand are applied in the Sprint Review: This is because, based on them, the Product Owner will decide whether to accept the user story or not.

"Done" or not "Done"¶

During the Sprint Review, all items that are "Done" according to the Definition of Done are presented.

PBIs that are not fully completed are not presented and are not accepted - even if they are mostly finished. Partial acceptance of Increments cannot occur. Tasks or user stories that have not been completed or have been completed incorrectly by the time of the Sprint Review and entries that are not accepted by the Product Owner are returned to the Product Backlog. There they are re-prioritised and, if necessary, completed in the next Sprint. Entries that are defective or marked as "technical debt" are either implemented immediately or identified as a backlog item and processed according to the urgency and degree of criticality.

After the Product Owner has approved the user stories, the environment is analysed for any changes and, if necessary, adjustments are made to the Product Backlog. Feedback from stakeholders or the Product Owner can also lead to adjustments to the Product Backlog. The results of the meeting give the Developers feedback on the work done so far and ensure that information is provided for subsequent activities.