Sprint Review not just Sprint Demo

Reading time

4 min

At the end of the iteration, the team hold what Scrum calls a “Sprint Review”. It’s typically obvious to a new Scrum team that the iteration needs a Sprint Planning event at the start. The point of an iteration is to plan over a shorter horizon, so a planning event makes sense. However, it’s sometimes less obvious why a review is needed at the end. Most importantly, it is not always clear what that review should be doing.

The Sprint Review contains two key areas of activity, which can be considered “Inspect” and “Adapt”. As with any transition point, one part is looking backwards at what happened in the last Sprint. The other is looking forwards at how these events affect the future.

There is separately also a Sprint Retrospective, which is covered in a different Play. The Review and Retrospective are separate events, if sometimes confused with each other. The Sprint Review is about progress on the Product and the Retrospective is about improvement as a team. Both are needed because we need to progress both the product and the team.

The Sprint Review contains two key activities, which can be considered
“Inspect” and “Adapt”

About “Inspect”

The first part of the Sprint Review is the “Inspect” part. This is a chance to get everyone clear about what has been completed in the Sprint. Different people have been working on different parts. Even within the team, some people may not have a complete picture.

In the same way as the Daily Scrum allows the team to come together and get a shared understanding of status for each day, the Sprint Review allows the team to all get a common view on status at the end of the Sprint. The “Inspect” part of the event is also a chance for the team to celebrate. They have completed functionality to a “Done” state where it can be demonstrated and could be shipped to customers.

The Sprint Review is wider than the team itself. There will be stakeholders across the organization interested in the features being developed. They should also be at the review. Sharing understanding is a key outcome and everyone interested in the work should be brought up to date. Typically this will involve some demonstrations, but sometimes that’s not possible. It is still important for everyone to understand what work has been done.

The “Inspect” part of the Sprint Review is more than just a demo or a passive presentation. Knowledge sharing is indeed a key part of the event. But also this is a chance for interested parties to discuss what they have seen. This is a working session not a passive demonstration.

Taking action

It is common that when people see completed work, it generates new thoughts and ideas. Perhaps someone can see a problem with the implementation. Maybe there’s an opportunity to enhance what has been done. These should all be raised and discussed. That does not mean that every idea will instantly be implemented. New ideas should be discussed and logged. If it is agreed they could add value, they should be put on the backlog. The backlog is, after all, the list of all of the potential work.

About “Adapt”

Now we move on to the “Adapt” part of the event. Sometimes this is deprioritised or even forgotten entirely. A Sprint Review which is only a demonstration is not an effective control point. Having looked at what happened in the past iteration, we now review the plan for the future. There are generally three areas to review in the “Adapt” part.

We need to look at the items at the top of the current backlog. These are our existing plan. If we make no changes this will probably be the work done next. It’s useful for everyone to review the current priorities. Again, this is a working session and people should feel able to challenge the priorities.

Then we should look at internal change. What has the team learned over the Sprint? Are some items looking harder or easier than expected? How has progress overall been compared with expectations? Any of these changes could mean we choose to modify our plan. For example, if we have a fixed delivery date and progress has been slow, we might wish to discuss which items are likely to be delivered by the end date. We could then review whether this is the right prioritisation.

Finally we should look at external change. Has anything changed outside of the team? Are there new customers with different priorities? Have existing customers left leading to some functionality being less important? This will partly be led by the Product Owner. Typically the stakeholders external to the team will bring knowledge or questions.

Good practices

The key good practice for an Agile leader is to ensure that your teams are regularly performing Sprint Reviews. You will want to check that the right stakeholders are involved. Do people feel informed about what the team is doing? Are people telling you they lack information or understanding?

The second area to look at is how the reviews are performed. Do they cover both halves of Inspect and Adapt? Some coaching will likely be needed here. Are changes to the backlog being generated as a result of the review? Are the attendees engaged and involved and contributing to the review.