Working software is the primary measure of progress.
Seeing is believing.
Team Demo Abstract
Until people can see and touch the results of a Story or a Feature, it’s just an abstract concept, so the demonstration of working, tested systems to Customers (or their proxies) is a concrete, seminal moment. To this end, depending on the scope of the Solution, there are three demos prescribed in SAFe: the Solution Demo, the System Demo, and the Team Demo. The system demo provides an aggregated view of all of the new system that has been delivered by all the teams on the Agile Release Train (ART), while the solution demo is the primary measure of progress for the Value Stream.
This article describes the team demo. This is the traditional Scrum-prescribed ceremony whereby the team reviews the increment that results from the Iteration; some Kanban teams apply them as well. Planning and presenting an effective team 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 the Team Demos cannot be overstated—they provide the only way that immediate, contextual feedback can be gathered from sponsors and Customers. As such, each demo serves three important functions:
- It brings closure to the Iteration timebox, to which 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 purpose of the team demo is to measure the team’s progress by showing working stories to the Product Owner and other stakeholders and to get their feedback. This demo is a one- to two-hour demonstration of new functionality. The preparation for the demo begins during Iteration Planning, where teams start thinking about how they will demonstrate the stories they are committing to. Teams should be able to demonstrate every Story, Spike, Refactor, and new Nonfunctional Requirement (NFR). This “beginning with the end in mind” facilitates iteration planning and alignment and fosters a more thorough understanding of the needed functionality.
The demo starts with a quick review of the Iteration Goals and then proceeds with a walk-through of all the committed stories. Each completed story is demonstrated in a working, tested system. 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 overcommitment. These findings may result in further discussion in the Iteration Retrospective about how the next iterations can be better planned and executed. Figure 1 illustrates a team demo in action.
In addition to showing how well the team did within this latest iteration, the team also reflects on how well it is progressing toward its PI Objectives.
Attendees at the team demo include:
- The Agile Teams, including Product Owner and Scrum Master.
- Other ART stakeholders or Shared Services who were involved in the iteration.
- Business Owners, executive sponsors, Customers, and members of other teams—perhaps. While they may attend, their interests and level of detail are usually better aligned with the System Demo. Otherwise, the team demos may be at too fine a level of detail, and “demo fatigue” may result.
A sample team demo agenda is as follows:
- Review the business context of the iteration and the iteration goals
- Demonstrate each story, spike, refactor, and applicable NFRs; gather feedback
- Discuss any stories that were not completed and understand why (the answers may inform planning for the next iteration)
- Identify new current risks and impediments that may have emerged from the iteration or the demo
Below are some tips for a successful team demo:
- Limit individual story demo preparation by team members to about one to two hours
- Timebox the meeting to one to two hours
- Minimize PowerPoint slides
- Demonstrate only working, tested systems of completed stories (reference the “Definition of Done” section of the Release article)
- 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: 18 October 2015