At the end of each iteration and at the end of the release, the product is demonstrated to the key stakeholders, the Product Manager, the Product Owner, the Team Agility Coach, and the whole team. If possible, try to include some actual users as well.

The Product Demonstration is not just a presentation but is a conversation between the participants about what has been done and what to do next.

Why to do this practice

Demonstrations are the best way to keep stakeholders up to date on progress and also to obtain feedback on the developers’ interpretation of features and stories. The cadence for demos need not be synchronized with the development or delivery cadences. Demos are usually scheduled near the end of an iteration, but they can be conducted at any time a feature or story is ready for evaluation and the stakeholders are available. It is much more important to demo early and get corrective feedback early, than demo late and find significant disconnects that create technical debt in terms of necessary rework.

Who does this practice

Here are the roles involved in this practice:

• Team Agility Coach, who is the facilitator of the demonstration
• Product Owner, who is the primary sponsor of the meeting
• Full Agile Team
• Stakeholders
• Management

What to do

Inputs

The essential prerequisite is that everyone is available for the demonstration: the key stakeholders, the Product Manager, the Product Owner, the Team Agility Coach, and the whole team. If possible, try to include some actual users as well.

Inputs to this practice include:

• Increment plan
• Finished functionality
• Reports showing completion (including test results)
• Demonstration script
• The Team Agility Coach has prepared to facilitate the meeting

Approach

The Product Manager owns the demonstration and, often, the Team Agility Coach facilitates the meeting. The demonstration is informal.

The walkthrough should cover more than simply the technical aspects: discuss what has been done with the people skills and training and the processes required to realize the feature. Adjustments to priorities (new, revised, removed) in order to achieve value in the next iteration.

Here are steps:

1. The Product Owner gives an introduction to the demonstration.
   • The goals of the iteration
   • The commitment list and the stretch objectives
2. The whole team gives the demonstration.
   • Summary of what will be demonstrated
   • What functional tests were used to validate functionality
   • Demonstrate the functionality
   • Emphasis of what was added/corrected since the at demonstration
3. The Product Owner accepts the items
   • Declare which team-commitment items are complete
     • code-complete
     • integration-complete
     • verification-complete
     • validation-complete
   • Declaring which iteration goals were met
   • Accepting or rejecting the team velocity calculated by Team Agility Coach based on story points of completed team commitment items
4. The team and the Product Owner agree to return incomplete items to the team backlog (see Carry Over Work).

Tools and techniques

Items that are used in the course of conducting a demonstration include:

• Working product
• Reports
• Feedback instruments (e.g. questions, checklists).

Discussion

Here are issues to consider:

• Useful stakeholders are not present. If stakeholders are not present, you cannot get proper feedback.
• Managing expectations. When the product is only partially complete and not ready to be released, the stakeholders have to be very clear that it is not ready.
• It is good enough. If the customer is satisfied enough, consider releasing it… use it!

When to do this practice

As needed, but usually always in the last few days of an increment

Where to do this practice

The demonstration is conducted in a conference room or area near the team‘s work area.

Outcomes

The benefits of this practice include:

• Proves progress
• Maintains stakeholder trust and involvement
• Helps to gain feedback on developer interpretation of features/stories/needs