Seeing is believing.
Team Demo Abstract
“Working software is the primary measure of progress” (Agile Manifesto). Until customers, and indeed even the team, can see and touch a story or feature, it’s just an abstract concept, so the demonstration of working, tested software to customers (or their proxies) is a concrete, seminal moment, that is repeated every two weeks. This article describes the Team Demo. However, there are actually two demos prescribed in SAFe, the Team Demo and the System Demo.
- Team Demo. This is the traditional, Scrum-prescribed, ceremony (though attendees may be somewhat different, as the business stakeholders are better suited to the System Demo).
- System Demo. The System Sprint Demo is unique to SAFe, and provides an aggregated view of all the new software that has been delivered by all the teams in the Program. It is typically hosted by the System Team, but presented by Product Owners and Product Management to key business stakeholders.
Planning for, and presenting, an effective demo requires some work on the part of the teams, but without it they will not have the fast feedback they need to build the right thing.
The importance of demos cannot be understated—it is the only way that immediate, contextual feedback can be gathered from the sponsors (those who are paying for the work) and customers (those who will be using the work). As such, each demo serves three important functions:
- It brings closure to a development time box wherein many individuals have contributed to provide new value to the business
- It gives teams an opportunity to show the contributions they have made to the business, and to take some satisfaction and pride in their work and progress
- It allows customers and stakeholders to see working features and provide feedback
The Team Demo happens right at the end of the team’s sprint timbox, as is illustrated in Figure 1.
The purpose of the Team Demo is to measure the team’s progress by showing working software to the development team, Product Owner and other stakeholders. This feedback is structured as a 1-2 hour demonstration of new functionality. The preparation for the demo begins when the sprint is planned—teams start thinking about how they will demonstrate the stories during Sprint Planning. Teams should be able to demonstrate every Story, Spike, Refactor, and new NFR. This “beginning with the end in mind” facilitates sprint planning, alignment, and fosters a more thorough understanding of the needed functionality.
The demo starts with a quick review of the sprint goals and then proceeds with a walkthrough of all the committed stories. Each completed story is demonstrated in working, tested code. Spikes are demonstrated via presentation of findings. After all completed stories are demonstrated, the team reflects on which stories were not completed, if any, and why the team was unable to finish them. This discussion usually results in discovery of impediments or risks, false assumptions, changing priorities, estimating inaccuracies, or over-commitment. These findings may result in further discussion about the how the next sprints may be better planned and executed.
Figure 2. Showing working, tested software at the team demo
Attendees at the Team Demo include:
- The Team: Product Owner, Scrum Master, and Developers and Testers
- Other team members or Shared Resources who were involved in the iteration, including QA, documenters, management, business analysts, tech leads, and architects
- Business owners, executive sponsors, customers, and members of other teams may attend, but their interests and level of detail is usually better aligned with the System Demo. Otherwise, the team Sprint Demos may be at too fine a detail to hold their attention, and “demo fatigue” may result.
A sample team demo agenda is as follows:
- Review the business context of the iteration and the sprint goals
- Demonstrate each story, spike, refactor, and applicable NFRs. Gather feedback
- Discuss any stories that were not completed and understand why (the answers to the “why” may inform planning for the next sprint)
- Identify new current risks and impediments that may have emerged from the sprint or the demo
- Briefly discuss upcoming features or stories
Below are some tips for a successful team demo:
- Limit individual story demo preparation by team members to 1 – 2 hours
- Time box the meeting to 1 – 2 hours
- Minimize PowerPoint slides
- Demonstrate only working, tested code of completed stories (reference the Definition of Done)
- If a major stakeholder cannot attend, the Product Owner should follow up to report progress and get feedback
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. Chapter 9.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. Chapter 15.
Last update: 10 May, 2013
© 2010-2013 Leffingwell, LLC. All rights reserved.