What is a Sprint Review, what is the procedure and what are the advantages as well as tips and tricks?
Sprint Review – Definition
The Sprint Review is a meeting at the end of a sprint to assess and approve the work done in relation to the set sprint goal. The Scrum Guide defines “A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.” Ideally, the team has completed each sprint backlog item, but more importantly, they have achieved the sprint goal agreed in the sprint planning. Only the items that were actually completed according to the Definition of Done are presented during the review.
Participants of the Sprint Review
The Sprint Review is attended by the entire development 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. The main focus of the meeting will be on the exchange of developers with the product owner. If the product owner cannot cover all technical aspects, the client should participate in the Sprint Review or send a representative. If this is not possible, the acceptance of corresponding user stories is 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. These include sprint planning, daily scrum and retrospective. Backlog refinement or grooming is also carried out regularly. The number of events or rituals alone indicates 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.
The Sprint Review in Practice
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 development team 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 are not permitted in the review.
- The team’s identification with its own work results increases.
- Ideas for further functionalities can be developed together.
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 one-month sprints, 3 hours or less for three-week sprints, and so on.
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. By explaining the sprint goal and naming the timebox, the participants gain 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.
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.
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.
Challenges for Companies
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 development team: “We are interested in your work and your results”. The alternative could be perceived as ignorance and even lead to demotivation.
We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the collection, structuring and administration of requirements and pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and consider stakeholders, goals and boundary conditions. And we plan and control your projects with these requirements on the basis of defined processes.