Skip to content

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.

The Product Owner does not have sufficient technical knowledge?

If the Product Owner, as the customer's representative, is not technically capable of testing and accepting the Increment, the customer should participate in the Sprint Review himself or send another representative.

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.

Do you remember what the abbreviations INVEST and CTF stand for?

INVEST stands for:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

CTF stands for:

  • Clear
  • Testable
  • Feasible

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.

Exercise question: What does the Definition of Done say?

The Definition of Done (DoD) is an important agile tool that helps teams plan and execute work. The Definition of Done is a set of criteria that the product must meet in order to be considered done. Even if not all user stories have been implemented, the Sprint can be defined as "Done" if the Sprint Goal has been met.

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.

Technical debt

A technical debt is when a user story is not perfectly implemented and the Developers are already aware that improvements will have to be made in the future. This is accepted when time is short. The growth of the technical debt with each new Increment increases the complexity of the product and reduces the Velocity.

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.

Overview: Sprint Review

  • Participants: Scrum Team and stakeholders, if applicable customers
  • Duration: Maximum 1 hour per Sprint week
  • Result: Product Owner determines the achievement of the Sprint Goal, live demonstration of the Increments and feedback from stakeholders and the Product Owner