Sprint Demos Guidelines

This document provides a set of standards relating to sprint demos which apply to people of all job roles.

The purpose of sprint demos is to demonstrate the business value of the features that the team have delivered within the previous sprint. The “business value” element is crucial here, and to highlight why this is so critical it’s worth stating what sprint demos are not designed to do:

• This is not a delivery team’s opportunity to march through the various PBIs that have been implemented in order to evidence that they have done work.
• This is not a delivery team’s chance to recount the challenges they faced.
• It is not a forum for the delivery team to show other team members what they’ve been working on - it is for the benefit of the Product Owner, SMEs and stakeholders.

It is worth the Scrum Master constantly reminding themselves of the above, such that they can encourage the team to frame everything in terms of the business value delivered.

1. Demo each sprint.
   1. Each sprint, a meeting should be held with the delivery team, Product Owner and relevant SMEs/stakeholders such that they can see what has been delivered over the course of the last sprint.
   2. Sometimes, the sprint demo will happen during the same meeting as the sprint review and sprint planning. In other instances, the sprint planning meeting might be separate. This will vary based on the nature of the project, so the approach can be tailored by the Scrum Master if they wish, provided the demos do happen each sprint.
2. Create sprint demo preparation calendar invites.
   1. The Scrum Master should place a recurring reminder in the calendars of those who will be doing sprint demos.
   2. This invite serves as a reminder that team members need to notify the Scrum Master of the items they plan to demo during the sprint demo meeting.
   3. The reminder should highlight that the team members need to send the Scrum Master a list of PBI titles and PBI numbers for items they plan to demo, such that these can be captured in the sprint demo notes.
   4. This invite should remind the team members that they need to set some time aside to prepare for their demos.
3. Consider which work items warrant a demo.
   1. Product Backlog Items:
      1. As a general rule, all Product Backlog Items that have not been demonstrated before and have been delivered to the QA environment should be shown, assuming the delivery team have a good degree of confidence that the feature is solid.
   2. Bugs:
      1. If bugs have been identified during development or QA, it is only worth demonstrating Bug cards if they are a change of functionality, have had a lot of business focus, or add value that should be celebrated.
      2. If bugs have been identified by the client, the Scrum Master may choose for these to be shown. This is at the discretion of the Scrum Master for the project in question. As an example, if the Product Owner has a high degree of confidence in the Delivery Team and knows that when they say “it’s fixed” then it will be, demonstrating a bug fix may not add sufficient value.
   3. Do consider demonstrating tests written if these can be framed in terms of the business value they add.
4. Focus on business value.
   1. The focus of these demos is to display business value. It is not an opportunity to recount the challenges we had during development, unless relaying this context helps improve the project delivery process overall or somehow impacts the planning of future work.
   2. In terms of what the business value is, this should be documented in the Product Backlog Item.
      1. If the title is in the form As a [role], I want [objective], for [motivation], the business value is the motivation element.
      2. This may be elaborated on within the Description section of the card. The person implementing the feature should be cognisant of the business value provided when they start work on the card, such that they keep this in mind throughout.
      3. As an example:
         1. The feature might be “As an Adminstrator, I can configure permissions for the tasks list, such that read-only users cannot edit it”.
         2. When the person doing the demo introduces it:
            1. Do not say “This sprint, I have been making a load of permissions confguration changes”.
            2. Do say “I have been working on allowing Administrators to control whether someone can edit the task list”.
         3. Note that in the above example we are expressing things in terms of the business outcome, rather than the implementation tasks that needed to be actioned in order to realise this outcome.

1. Practice the demo.
   1. The developers or testers running the demos should practice the demo in advance, leaving sufficient time to rectify any issues prior to the sprint demo meeting to ensure that everything works.
2. Prepare test data.
   1. The person running the demo should:
      1. Make sure any requisite test data is set up in advance.
      2. If they are running from a local build (generally not recommended), consider creating a branch specifically for this.
   2. Use realistic data. This helps the audience to contextualise the feature being demonstrated and minimises cognitive overhead here. It also helps give a sense that the feature is finished and production-ready.
   3. Use data that allows us to display the real-world workflow. As an example, if the feature is “filling out timesheets for a team” and the typical team consists of 5 people, we would populate our teams with around 5 people to allow feedback such as Could we have a ‘copy row’ button please? which might not get highlighted if we demonstrate with 1 team member only.
   4. Consider inclusion of extreme cases. As an example, if an input field has been specified as one that accepts a maximum of 200 characters, it may be worth having an example of this within the test data configured. This will allow the client to see what would happen if a user populates this field with 200 characters with no spaces.
3. Prefer to demo complete features.
   1. Generally, we should be demonstrating complete features. This means demos should usually be run from the QA environment, rather than local developer builds.
   2. If a feature is not complete (i.e. has not undergone internal QA), it is generally worth saving the demo until the next sprint demo.
   3. In some instances, there is a case for running a demo from a someone’s local PC:
      1. If feedback is actively sought and the audience on the call are the correct people to provide this feedback, the Scrum Master may choose to approve a demo being run from a local machine. This may provide reassurance that an overarching feature that is comprised of multiple separate PBIs is heading in the right direction. However, the person doing the demo and the Scrum Master should consider whether a separate meeting would be a better forum for this.
      2. If a large feature is being worked on but cannot be completed in a single sprint, we may choose to demo a work in progress feature to help evidence the good work being done. The rationale is that when the Product Owner or stakeholder sees positive momentum, they are more inclined to contribute their time to the project.
      3. In some cases, receiving feedback early is useful, because we can action feedback prior to deploying the feature to QA, which reduces re-work effort overall.
      4. Seeing a new feature provides the context that a Product Owner needs in order for them to visualise how the next feature they’re defining should be built, potentially improving the quality of acceptance criteria on future cards.
   4. There are a number of reasons for avoiding running demos from local PCs, including:
      1. Local demos often fail e.g. because the developer is on the wrong branch, or is missing some data, or some other technical reason that is irrelevant to the client.
      2. It can encourage last-minute code changes (which should be avoided).
      3. It implies the feature hasn’t been tested yet; generally speaking, we shouldn’t be demonstrating something to a client if we haven’t tested it yet.
4. Avoid last-minute code changes.
   1. Do not attempt to make last minute changes to code immediately prior to the demo.
   2. If an issue is found, it will often be better to postpone the demo until the next meeting rather than rushing to show something that may not work.

1. Introduce the feature before starting.
   1. Focus on business value. If a feature allows the business to do something that gives them value, start by introducing the feature within this context.
   2. Do reference the card / cards on the project board before launching straight into the demo.
      1. This may involve reading out the card title, or displaying the card on screen and refreshing peoples’ memories on the agreed acceptance criteria.
      2. As well as adding structure to the demo, this helps reinforce the idea to people who are new to agile that “all our work comes from the project board… so if the Product Owner successfully feeds high quality requirements into the project board, they get well built software as a result”.
      3. It may make sense to demo multiple related PBIs together, in order to better tell the story. In this case, it’s fine to group them rather than splitting the demo and showing the PBIs in between each section.
   3. Bear in mind that you have likely been working on the feature in-depth and you know it well, but the audience will likely need cues to remind them what we’re talking about.
2. Use a presentation sandwich structure.
   1. When running a demo, it is worth considering the classic rules for running effective presentations:
      1. Tell the audience what you’re going to say
         1. This may involve simply reading out the title of the PBI that is being demonstrated.
      2. Say it
      3. Tell them what you’ve said
         1. This is a recap so that the audience are reminded of the scope of what they’ve just seen.
3. Tell a story.
   1. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
   2. If multiple people have worked on a single feature, it might be worth agreeing in advance that one person will demo all aspects, rather than hopping between different people.
4. Keep it short.
   1. You don’t need to exhaustively cover all your acceptance criteria in your demo, despite the fact that the edge cases are often the areas that caused the biggest challenges during development. Instead, focus your demo on what’s interesting and valuable to the business.
   2. As an example, if the feature is a form with multiple fields, it will be worth showing the happy path through to submission, and that there is field validation. However, we don’t need to evidence the validation on every single field in the form.
5. Praise the delivery of good results.
   1. This is the perfect opportunity for the Scrum Master to highlight the hard work that has gone in to development of the feature.
   2. It might also be worth praising the Product Owner or SMEs if applicable e.g. “The clear acceptance criteria and comprehensive test cases supplied really helped me develop this feature quickly and allowed me to get it right first time.”
6. Prompt for feedback.
   1. Feel free to ask questions such as “Is this what you anticipated?” or “Do you feel this will be intuitive and well-received by end users?”.
   2. The person running the demo is of course free to prompt for feedback. If they don’t, the Scrum Master should generally prompt the Product Owner for positive confirmation that this feature looks good to them.
7. Mention current status.
   1. For example, if the feature is not yet in the UAT environment but is planned for the next release, feel free to mention this when closing off the demo so that the client knows when they are likely to get their hands on this feature.
   2. If the feature being shown is a precursor to another feature that we’ll be moving on to immediately after this, it may be worth highlighting this to help provide additional context.

1. Record feedback
   1. The Scrum Master is generally responsible for capturing the feedback that emerges from demos. This frees up the person who is doing the demo to focus on actually running the demo.
   2. Generally, this will result in the creation of new Product Backlog Items or Bugs such that feedback can be addressed.
   3. If the Scrum Master is performing a demo, they should nominate someone else to capture feedback on their behalf while they demo.
2. Encourage feedback.
   1. Avoid being defensive. It is perfectly possible that acceptance criteria was wrong the first time, or that the desired functionality has now changed following the demo. We should embrace change on agile projects and capture feedback that emerges even if it feels that the goalposts are moving. Once any effort for changes has been estimated, we can always decide whether to prioritise changes as a separate discussion with the Product Owner.

1. The Scrum Master should maintain a record of items demonstrated within the meeting notes, and these should be published on the project wiki following the meeting.

If a demo fails:

1. If the person doing the demo is expecting things to work and they don’t, this can be very uncomfortable for them and there’s no need to add to the stress here. The Scrum Master or Technical Lead should be willing to cut the demo short and postpone the demo until the next meeting, or arrange an ad-hoc session. There is generally no value in encouraging the person running the demo to rush and try and get things working within a compressed timeframe. It is important to make people feel at ease and create a positive “single team” atmosphere. It is incredibly rare that a demo cannot be postponed without impacting project delivery more generally.
2. These things happen. The person doing the demo should not be attacked within this public forum. If they’re falling short of expectations in this sense, this should be discussed sensitively in private.
3. If the demo could have been better prepared for, the Scrum Master should consider organising a demo preparation meeting with the person doing the broken demo in advance of the next client-facing demo meeting. This gives them a forum in which they can practice the demo in advance.