Agile: Overview of Sprint Review Meeting

The Sprint Review Meeting is held at the end of each sprint, the sprint review meeting is an informal gathering of the Scrum team where product backlog items that have been completed during the sprint are presented.

Product backlog items that have not been completed are not presented at the meeting, instead, they returned to the product backlog, re-estimated and added to a subsequent sprint.

Why have a sprint review meeting?

Holding a sprint review meeting creates transparency between the scrum team and stakeholders, optimising value.

It is important to remember that the review meeting’s purpose is to gather feedback from the team and reflect on that one individual sprint. It is informal, and presentation aids, such as PowerPoint, are typically banned. Although stakeholders are involved, the review meeting is not about providing status updates or presentations to them.

Who is involved?

The whole scrum team will be present at the review meeting, in addition to key stakeholders that are invited by the product owner.

How long is the meeting?

The length of a sprint review meeting will be time-boxed. Meetings should last no longer than four hours for a monthly sprint however the time-box is set according to the sprint’s duration.

Meeting preparation

A number of items should be prepared prior to the meeting. These items are self-organised by the scrum team, with the assistance of the scrum master.

A refined product backlog
The sprint goal, which identifies the progress made and the work that is known to be remaining.
The most recent product increment
An agreed definition of “done”.
A list of things that went well during the sprint alongside any challenges that the team faced and how they were addressed.
Learnings from the marketplace
Expected projections
The product owner’s assessment of the progress made towards completing the projected work
The development team’s performance during the sprint
A projection of the development team’s capacity ahead of the next sprint

The sprint review process

The ideal sprint review has a pretty rigid format despite it’s informality.

Firstly, the product owner identifies which product backlog items have been “done” and “not done”. This is where having a previously agreed definition of “done” is essential to ensure that all members of the meeting are aligned.

Next, the development team express which aspects of the sprint went well, and where they experienced problems or challenges. The team will be expected to explain how those problems were rectified.

They will then demonstrate the work that they have “done”, answering any questions about the increment.

Once this feedback has been gathered from the sprint, all members of the meeting will collaborate to decided what to do in the next sprint. This ensures that valuable input is gained for subsequent sprint planning.

A major aspect of the sprint review meeting is to provide value. To do this the team must hold a review of the marketplace and the potential use of the product to identify if any changes have occurred. This information will provide the basis of choosing the most valuable thing to do next.

Finally, there should be a review of the timeline, budget, potential capabilities and marketplace for the next planned release of product functionality or capability.

Overcoming disagreements

It is somewhat inevitable that a sprint review meeting will feature disagreements, or mis-alignment, between participants, particularly in large meetings.

Expectations

There is often an expectation from stakeholders that a product backlog item must be “done” before the sprint ends. To combat this, the scrum master should help stakeholders to understand the concept and value of incremental development and continuous improvement.

Providing the development team have, reasonably, done all that they can, creatively and productively, then they can be deemed to have met their commitment despite not meeting the sprint goal or completed all forecasted product backlog items.

Demand of certainties

Scrum teams must remain adaptable to newly discovered value and complexity, and as such are unable to provide fixed certainties to stakeholders. This can cause tension with stakeholders, particularly if they are not experienced in Scrum, and are more familiar with having rigid deadlines as opposed to employing continuous planning.

The most effective way to combat this is to share past projections of the development team’s performance, showing their reliability even in complex situations.

Making unpopular decisions

The product owner may have to make decisions on the order of product backlog items which prove to be unpopular. The interests of stakeholders may not be compatible with the capability of the development team based on what the product owner knows about their past performance.

There is an old saying that, “you can’t please everyone all of the time”, and here it is especially true. Stakeholders must respect the decisions that the product owner makes even if they aren’t favourable to them.