Scrum in practice: the sprint demo

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 the product owner and Scrum master, 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 turns 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 into 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 on the order of the stories in the demo — and make notes on anything we need to set up 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.