Sprint Demo

63 team-sprint-demo

The Sprint Demo, also known as the Team Demo, is the team’s opportunity to show that they have met the agreed upon, overall goals for the sprint. The demo is informal and uses working software to show that all of the team’s commitments were completed during the sprint.

Explore More.

Related Mindset:





The input for the Sprint Demo is a coded, testable and functional unit of working software.


The output of the Sprint Demo is immediate customer feedback, and a potentially shippable product increment.

The Sprint Demo, often a part of the larger Sprint Review Meeting, is a critical piece of the Agile scrum process.

The sprint demo occurs at the end of each sprint, and is the opportunity for the team to showcase completed work from the current sprint to the Product Owner and the appropriate internal stakeholders. This may include financial decision makers, management, and influencers. It can also include some external representatives including target users.

Sprint demos provide a transparent view of measurable progress, and are a vehicle for open communication and feedback between the team and all stakeholders. They give customers and the larger community the chance to see working features and provide comments. Continuous, quick feedback helps ensure the team is continuing to build and deliver working software that provides value.

Some general guidelines for running an effective Sprint Demo:

  • The meeting should be informal, open and collaborative.
  • The meeting should be timeboxed to a maximum of 1 hour per number of weeks in a sprint. For example, a two week sprint should be timeboxed to two hours.
  • The meeting should focus on the working software. There shouldn’t be any PowerPoint presentations. With this focus, the meeting should require minimal preparation.
  • The Scrum Master should invite the scrum team, business owners, decision makers, customers, and all appropriate internal and external stakeholders.
  • The meeting is led by the Product Owner, demoed by the developers, and facilitated by the Scrum Master.
  • The team should only demo complete, functioning, shippable features. - This is the time to discuss and share why any stories were not completed in the sprint.
  • One primary goal of the meeting should be to solicit feedback around the value that is delivered to users through this functionality.
  • All feedback should be placed in the Backlog for future consideration and prioritization. Prioritization of this feedback should not be discussed in this meeting.
  • Identify and document any new risks that may arise as a result of the Demo.

Common Pitfalls

While many organizations are adept and proficient with Agile, there are problems that can occur during a Sprint Demo that can derail a team or project:

  • Using the Sprint Demo as a ‘Sign-off’ or ‘User Acceptance’ Meeting - It is great to get feedback during a Sprint Demo, but using it as a sign-off meeting can cause scope creep in the current Backlog, minimize the Agile Product Owner role, and create walls between the various teams and the stakeholders.
  • Demoing Unfinished Work - While it can be tempting to demo work that is well underway but not yet completed as a way to get feedback, this often leads to team miscommunication and a lack of transparency to stakeholders on the state of the work. By only demonstrating finished work, teams can more accurately track, review, and report their progress.
  • Not Having the Right Audience In Attendance - Sponsors, major stakeholders, and real users can all provide valuable feedback in the Sprint Demo. If key individuals are not present, it will hinder the team’s ability to make both difficult and real-world decisions that could have a far reaching impact on the initiative. In addition, getting feedback from individuals that don’t have influence will delay work and steer the project in the wrong direction.


In most cases, the Sprint Demo will include a collection of on-site and remote attendees. With this being the case, the technology that the solution is being built in will have an impact on how the solution is demoed. Even in situations where mobile experiences are being shown, tools can be used to give all attendees a preview.

Screen Sharing Software

Android Emulators
Android Studio Emulator
Genymotion Emulator

Mobile Mirroring
Quicktime (iOS)
Reflector (iOS and Android)
AppleTV (iOS)