Scrum in practice: the Sprint Demo

In Scrum the goal of each iteration is to produce a working increment of the product which can be demonstrated to stakeholders. Naturally then, one of the key meetings in a Scrum sprint is the end of sprint demo (also known as the Sprint Review Meeting).

Here the work that the Scrum team has completed in the sprint is demonstrated and the progress of the team is assessed against the sprint goal.

Purpose of the sprint demo

The sprint demo is invaluable for keeping stakeholders up to speed with the progress of product development. It allows them to feedback and discuss with the Product Owner and Scrum team any possible amendments to the Product Backlog which would help to maximise value.

Such discussions can inform the planning of the next sprint and the contents of the next sprint backlog. They will often result in stories being added further down the product backlog too.

Format of the sprint demo

The sprint demo takes place at the end of the sprint and is attended by the whole Scrum team, including Product Owner and ScrumMaster, as well as relevant stakeholders, management and developers from other teams.

When an organisation has more than one Scrum team working on the same project the teams should consider running their demo together. It’s not just easier to arrange this way – it keeps teams abreast of what the others are working on, which facilitates the sharing of insight and helps to avoid the duplication of work. However at a certain size this may not be practical and representatives from Scrum teams attending each other’s demos may be more practical.

Each Scrum team takes it in turn to update on their progress against their sprint goal and demo the working iteration of the product that resulted from their sprint. Generally I like to do this by user story, with the stories organised in to a logical narrative structure.

Sometimes the team will nominate a member to present the demo and sometimes the task will be shared, with individuals demonstrating the particular parts of the increment they worked on. Again, a personal preference, but I think demos work well where one person leads on the talking and one leads on the demo element.

Preparing for the sprint review meeting

The sprint demo shouldn’t take up too much of a Scrum team’s time. Ensuring that the sprint review meeting is an informal affair – where questions, feedback and discussion are welcome – allows for prep time to be kept to a minimum.

Time shouldn’t be spent putting long slide decks together – the focus should be on the work and the demo should only include stories that meet the team’s definition of Done.

Generally a day or two before the end of the sprint I hold a short demo run-through with the team in which we agree the order of the stories in the demo – and make notes on anything we need to set up in order to make the demo flow well. This meeting is kept short (say 15 mins) – but ensures the team have thought the demo through.

Finally it’s important to say that the Sprint review is not a sign off meeting. The Product Owner should have already seen the stories and be happy with them. Discussion and feedback are encouraged – but while this might result in new backlog items, it shouldn’t change whether existing items are considered done.