What is a System Demo?

A System Demo is a significant event in the Scaled Agile Framework (SAFe) that provides an integrated view of the new features delivered by all teams in the Agile Release Train (ART) during the most recent iteration. Unlike individual team demos that showcase a single team's work, the System Demo demonstrates how all the pieces fit together as a cohesive, working solution.

The System Demo is one of the most important feedback mechanisms in SAFe because it provides stakeholders, management, and the teams themselves with an objective measure of progress. It answers the critical question: "Does the integrated solution actually work as intended?"

In practice, the System Demo is where the rubber meets the road. Individual team demos may show features working in isolation, but the System Demo reveals integration issues, dependency problems, and the true state of the overall solution. This makes it an invaluable tool for managing risk and maintaining transparency in large-scale development.

The System Demo serves several critical purposes within a SAFe implementation:

• Objective assessment - provides an honest evaluation of the current state of the solution, based on working software rather than status reports
• Integration validation - verifies that work from multiple teams integrates correctly and functions as a whole system
• Stakeholder alignment - keeps business stakeholders informed and engaged, ensuring the solution meets their expectations
• Feedback acceleration - shortens the feedback loop by enabling stakeholders to see and interact with working features every iteration
• Risk reduction - surfaces integration issues early, before they compound into larger problems
• ART synchronization - ensures all teams share a common understanding of progress and remaining work
• PI objective tracking - provides data to assess progress toward Program Increment (PI) objectives

SAFe recommends the following parameters for the System Demo:

The regular cadence is essential. Skipping System Demos, even when there seems to be little to show, undermines the discipline of continuous integration and feedback. Every iteration should produce a demonstrable increment.

Required participants

• Release Train Engineer (RTE) - facilitates the event and ensures it runs efficiently
• Product Management - evaluates the increment against business requirements and PI objectives
• System Architect/Engineer - assesses technical integration and architectural compliance
• Team representatives - developers who can explain and demonstrate their contributions
• Business stakeholders - provide feedback and validate business value

Optional participants

• Solution Architect - for Large Solution SAFe contexts
• Customers - when direct customer feedback is valuable
• Supporting teams - infrastructure, security, UX, and other enabling teams
• Management - for visibility into progress and impediments

Effective System Demos require careful preparation:

Before the demo

1. Integrate early and often - teams should continuously integrate their work throughout the iteration, not just at the end
2. Set up the demo environment - ensure the staging/integration environment reflects the latest integrated code
3. Define the demo script - create a logical flow that shows how features work together, not just individual team contributions
4. Rehearse - a quick dry run catches environment issues and timing problems before the actual event
5. Prepare for failures - have backup plans if the live demo encounters issues

Demo environment

The demo should run in a staging or integration environment that is as close to production as possible:

• All team code must be merged and deployed
• Test data should represent realistic scenarios
• The environment should be stable and not actively being modified during the demo
• Automated CI/CD pipelines should handle the deployment

Recommended flow

1. Brief context setting (5 min) - the RTE provides a brief overview of the iteration's objectives and what will be demonstrated
2. Live demonstration (40-45 min) - features are demonstrated in a logical flow that shows integration and end-to-end scenarios
3. Feedback and discussion (10-15 min) - stakeholders ask questions, provide feedback, and raise concerns
4. Assessment (5 min) - a quick assessment of progress toward PI objectives

Best practices for the demo itself

• Show working software - the demo should always be live, running code in an integrated environment. Slides and mockups defeat the purpose
• Follow user journeys - demonstrate features as a user would experience them, not as technical components
• Highlight integration - explicitly show how work from different teams connects and functions together
• Be honest about issues - if something does not work, acknowledge it. The System Demo is about transparency, not marketing
• Focus on business value - explain what the features mean for users and the business, not just what was technically implemented

The System Demo and the team-level Sprint Review serve different but complementary purposes:

The team Sprint Review happens first, where individual teams demo their work. The System Demo aggregates these into an integrated view, revealing how the pieces work together.

The System Demo often reveals integration challenges that are invisible at the team level:

Common integration issues

• API contract mismatches - teams build to different assumptions about shared interfaces
• Data inconsistencies - different teams handle data formats or states differently
• Performance degradation - features that work fine in isolation may cause performance issues when integrated
• UX inconsistencies - different teams may implement inconsistent user experiences
• Dependency conflicts - shared libraries or services may have version conflicts

Addressing integration issues

• Continuous integration - teams should merge and integrate code multiple times per day, not just at the end of the iteration
• Shared standards - define and enforce coding standards, API contracts, and architectural guidelines
• Integration testing - automated integration tests should run in the CI/CD pipeline
• Architecture runway - the System Architect maintains an architecture runway that anticipates integration needs
• Communities of Practice - cross-team communities help align practices and share knowledge

Progress metrics

The System Demo provides data for several important metrics:

• PI objective completion - percentage of PI objectives achieved or on track
• Feature completion - number of features demonstrated and accepted
• Integration health - number and severity of integration defects found
• Velocity - aggregate ART velocity across all teams
• Demo readiness - whether the team was able to demonstrate in the integrated environment (a proxy for integration maturity)

Assessment approach

After the demo, stakeholders should assess:

1. Is the solution progressing as expected toward PI objectives?
2. Are there significant integration issues that need attention?
3. Does the demonstrated functionality meet business expectations?
4. Are there emerging risks that require mitigation?
5. Should priorities be adjusted for the next iteration?

For large ARTs (10+ teams)

• Focus on end-to-end scenarios rather than team-by-team presentations
• Use pre-recorded segments for individual team features, with live integration demos
• Extend the timebox if necessary, but maintain engagement
• Consider splitting into multiple themed demos with a final integration session

For Solution-level demos

In Large Solution SAFe, the Solution Demo aggregates System Demos from multiple ARTs:

• Demonstrates the integrated work of the entire solution
• Occurs at the end of each PI (not every iteration)
• Is facilitated by the Solution Train Engineer
• Includes Solution Management and Solution Architect

• Slide demos - showing slides instead of working software defeats the entire purpose
• Team-by-team format - showing each team's work in isolation misses the integration perspective
• Skipping when "nothing to show" - every iteration should produce demonstrable progress; skipping hides problems
• Not rehearsing - environment issues and timing problems are easily caught with a brief dry run
• Filtering bad news - the System Demo must show the real state of the solution, not a polished version
• No stakeholder attendance - without stakeholder feedback, the demo loses its primary value
• Demo only at PI boundaries - the System Demo should happen every iteration, not just at PI events

What is a System Demo in SAFe?

A System Demo is an event in the Scaled Agile Framework (SAFe) where the integrated work from all teams in an Agile Release Train is demonstrated to stakeholders at the end of each iteration. It shows how features from multiple teams work together as a cohesive solution, providing an objective assessment of progress.

How is a System Demo different from a Sprint Review?

A Sprint Review showcases a single team's work at the end of a sprint. A System Demo showcases the integrated work of all teams in an ART. Sprint Reviews happen at the team level and are facilitated by the Scrum Master; System Demos happen at the ART level and are facilitated by the Release Train Engineer. The System Demo focuses specifically on integration and the overall solution.

How long should a System Demo last?

SAFe recommends a timebox of approximately 60 minutes for the System Demo. For larger ARTs with many teams, the timebox may need to be extended, but it is better to focus on key integration scenarios than to try to show everything. Preparation and rehearsal help keep the demo within the timebox.

Who facilitates the System Demo?

The Release Train Engineer (RTE) facilitates the System Demo. The RTE is responsible for ensuring the event is well-organized, stays within the timebox, and produces meaningful feedback. The RTE coordinates with team representatives and Product Management to define the demo script and flow.

What should be demonstrated in a System Demo?

The System Demo should show working, integrated software in a staging or integration environment. Focus on end-to-end user scenarios that span multiple teams' contributions. Highlight how features integrate together rather than showing individual team outputs. The demo should be live software, not slides or mockups.

What happens if the System Demo reveals integration issues?

Integration issues discovered during the System Demo should be prioritized for the next iteration. The RTE and System Architect work together to assess the severity and assign resolution. Persistent integration issues may require changes to team practices, architecture, or the CI/CD pipeline. This is one of the most valuable aspects of the System Demo: finding problems early.

Should the System Demo happen even when there is little to show?

Yes, absolutely. Skipping the System Demo when there is "nothing to show" is a red flag indicating potential problems with continuous integration or team progress. Even small increments should be demonstrable. The discipline of regular demos drives teams to integrate frequently and maintain a working solution at all times.

How does the System Demo relate to PI Planning?

The System Demo provides ongoing feedback that informs the next PI Planning event. The cumulative results of all System Demos during a PI are assessed at the Inspect and Adapt event, which directly feeds into PI Planning priorities and objectives for the next increment.