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.

Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. Lisa Campbell says:

    There is a discussion in our shop on *who* should run the demo. Presently, the QA team is running it. The Product Owner is wanting Dev to run it. In my previous job, the demo was run by the Business Owner and/or QA.


    • Jeff says:

      I guess it depends who is attending the demo. If it is a demo from the team to the PO, then a member of the dev team is fine. Assuming the demo is to a broader audience, stakeholders, etc. then in my opinion I think the product owner (or maybe the BA) should demo the software. If the product owner/BA is truly part of the team, working daily with them, then the s/he should be in lockstep with the dev team and it is an opportunity for the PO/BA to walk through the feature(s), being able to answer specific business related questions/reasoning. I’ve seen situations in the past where a member of the dev team would demo to a broader audience, including the PO/BA, and there were disconnects – which of course raised other concerns. In either situation, I’ve never seen a QA resource be the person to conduct the demo.

  2. Reuben Tonna says:

    We have a running debate as to when the sprint review contents should be preferred. The scrum master tends to ask for a plan of what will be shown on the same day we plan the sprint. We have 2 week sprints. Is such a way of preparing for this the right approach?

    • Gemma Reeve says:

      The demo is a point in time for the team to demonstrate the work produced as part of that sprint, as so, planning for that sprint should be done at the end. I would assume the reason the Scrum Master wants know the demo plan is so that they can ensure the right stakeholders are in the room for the demo. However, they should be assuming that whatever has been agreed to take into sprint is what might be shown at the demo, with the obvious caveats to stakeholders that the situation may change due to any unforeseen blockers or additional work that prevented the team from achieving the sprint goal.
      At Manifesto, we usually plan the demo’s out 1-2 days before the sprint demo because at this point we have better visibility around what items have meet the ‘definition of done’ and as so are ready to demo. Ahead of the demo the team will:

      1) Create a list of completed stories & those that are not
      2) Create some scenarios that the stories will fit into
      3) Run through the demo as a small development team
      4) Agreement as a team on who is going to demo – either one person to lead or multiple people covering their areas
      5) Generate a “pre-flight” checklist that needs to be completed before the demo i.e. to ensure that any sample content is created, any necessary pages are already opened or bookmarked, the software is in the correct state.

      I hope that’s helpful. If you have any further questions please do let us know.

  3. Deryacenter says:

    The Development Team demonstrates the “Done” functionality (Demo), answers the questions and discusses problems they met on their way.

  4. […] the very early stages of the progress, we instigated bi-monthly demos in which the team gave project updates. The demos were inclusive to anybody in the business but we […]

  5. Fantastic web page you have right here, i
    do conchur on some items even though, but not all.

  6. Cassio Castro says:

    Thanks for the explanation! 🙂

  7. Eric says:

    We are having the same conversation about who should be doing the demo. I agree that if it’s an internal demo, then it should be lead by the developers. Developers can walk to PO/BA through what was developed and how it functions. In our case as a consulting company with external stakeholders, I think the BA or PO should demo to the client. The BA/PO should be able to answer questions/document requirements etc.

Sign up for the Manifesto newsletter and exclusive event invites