Provide a summary of this practice.
The Showcase is the event where the team demonstrates to the Product Owner and others the software they have created to deliver the agreed User Stories.
What is the overall goal or intention of this practice?
The Showcase (also known as a ‘sprint review’, ‘demo’ or ‘show-and-tell’):
It is not the Showcase’s purpose to obtain approval or acceptance.
What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?
What must have happened or been delivered for this practice to be considered complete?
The Showcase is complete when:
What pre-conditions must be met before this practice is used?
Stories must be mature enough for ‘live’ demonstration.
This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.
|1||Schedule the meeting.|
|3||Rehearse Product Owner.|
|4||Introduce the session.|
|6||Review remainder of release|
|7||Close the meeting.|
|1||Schedule the meeting.||Iteration Lead.|
|3||Rehearse Product Owner.||Iteration Lead.|
| Verify that the Product Owner is comfortable with:|
|4||Introduce the session.||Product Owner.|
|6||Review remainder of release||Team.|
|7||Close the meeting.||Product Owner.||Questions to the audience might include:|
|8||Update backlog.||Iteration Lead.|
Issues & risks
What are the key concerns in making a success of this practice?
- Given the very close relationship between the user representatives, the Product Owner and the team, the Showcase should not be the first time the Product Owner has seen most of the stories being demonstrated. There should be few surprises or disputes.
- As the Showcase takes place close to the end of the iteration, it generally leaves only enough time for quite minor fixes and improvements. So effective user involvement throughout development is essential, to ensure that the showcased stories are readily accepted.
- A story is only fully ready for the Showcase if it meets all the requirements of your Definition of Done. However, if the team would like feedback on work in progress, it may also include incomplete stories (provided that they are introduced as incomplete).
- Never present ‘rigged’ functionality, (e.g., hard-coded values) as working software.
- You may have more than one Showcase if stories can be clearly partitioned out. This may allow you to stage testing, user training and other activities more efficiently.
- Showcases are intentionally informal occasions. This helps to encourage open feedback and exposes any new information that will help the team to finalise the iteration. To achieve this, preparations should be minimal (e.g., with no initial slide show) and the meeting kept as light-weight as possible. So, although the procedure below includes many steps, most of them should take very little time.
- If the showcase results in new stories being identified, it is not usually appropriate to include them in the current iteration. Add them to the backlog for future prioritisation.
- You may want to include remote (e.g, offshore) teams in the demo (although rehearsing, scheduling and communications can be harder):
- Team members can provide better answers to the questions and feedback if they personally developed the items in question.
- Direct feedback is better than filtered comments.
- It builds transparency, confidence and trust between the team and the stakeholders.
- Being actively involved generates a sense of involvement and achievement.