At the end of each iteration the product is demonstrated to the key stakeholders, the product manager, the product owner, 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 iterations; 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 constructive feedback early, than demo late and find significant disconnects that create technical debt in terms of necessary rework.
The primary objective with demonstrating the results of the iteration is to gather feedback from stakeholders on implemented functionality and future planned stories. See Elicit Requirements process goal.
Who Does This Practice
Here are the roles involved in this practice:
- Product owner, who is the facilitator of the demonstration
- Full agile team
What to Do
The essential prerequisite is that everyone is available for the demonstration: the key stakeholders, the product manager, the product owner, and the whole team. If possible, try to include some actual users as well.
Inputs to this practice include:
- Iteration plan
- Finished functionality
- Reports showing completion (including test results)
- Demonstration script
- The product owner has prepared to facilitate the meeting
The product owner owns the demonstration and often facilitates the meeting. The demonstration is intended to be informal.
The walkthrough should cover more than simply the technical aspects: also 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 last demonstration.
3. Consensus is achieved with stakeholders as to which iteration goals were met and which weren’t.
4. The team and the product owner agree to return incomplete items to the product backlog for future continued development, in the next iteration or in the future.
Tools and Techniques
Items that are used in the course of conducting a demonstration include:
- Working product
- Feedback instruments (e.g. questions, checklists)
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, it has to be made clear to the stakeholders.
- 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 iteration.
The benefits of this practice include:
- Proves progress.
- Maintains stakeholder trust and involvement.
- Helps to gain feedback on developer interpretation of features/stories/needs.
Product Owner Overview
- Acceptance test-driven development
- Capturing functional requirements
- Controlling work-in-process (WIP)
- Daily coordination
- Decomposing a feature into stories
- Iteration demonstration and review
- Iteration demonstration and review (plan)
- Iteration planning meeting
- Iteration retrospective
- Operational metrics
- Unfinished work
- Visual controls