Seeing is believing.

– Anon

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.

Details

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.

Figure 1. Team demo in the SAFe sprint cycle

Purpose

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.

Process

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

In addition to showing how well the team did within this latest sprint, the team also reflects on how well it is progressing toward its PSI objectives. After the demo, the Retrospective is held.

Attendees

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.

Agenda

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

Guidelines

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

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. Chapter 9.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. Chapter 15.

Last update: 10 May, 2013