Conduct showcase

Conduct showcase2018-04-18T15:35:11+00:00

Showcase Workflow

Context

Summary

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.

Purpose

What is the overall goal or intention of this practice?

The Showcase (also known as a ‘sprint review’, ‘demo’ or ‘show-and-tell’):

  1. demonstrates to the Product Owner and other stakeholders the working, deliverable software required to implement the agreed features and stories.
  2. reviews overall progress, especially how well the sprint goals are being met and how to address problems and issues.
  3. fosters a collaborative relationship with story owners and other stakeholders.
  4. allows developers to rapidly identify issues they need to address before the end of the iteration.
  5. refreshes the backlog.
  6. keeps everyone aligned with  the real status and progress of work.

It is not the Showcase’s purpose to obtain approval or acceptance.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

  • Showcases normally take place towards the end of the iteration.
  • A Showcase should not normally last more than an hour for every two weeks of development.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

The Showcase is complete when:

  1. All the stories the showcased solution is meant to implement have been walked through.
  2. The Product Owner has approved (or otherwise disposed of) all iteration stories.
  3. The users and stakeholders’ feedback has been gathered.

Entry conditions

What pre-conditions must be met before this practice is used?

Stories must be mature enough for ‘live’ demonstration.

Outline process

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.

#StepInstructions
1Schedule the meeting.
  1. During Iteration Planning, agree an approximate time for the Showcase.
  2. Schedule the meeting.
2Rehearse team.
  1. Shortly before the scheduled time, rehearse the Showcase with the team members who will be actively involved:
  2. For each User Story:
    • Walk through how you plan to explain it.
    • Check the timing, including any options you plan to demonstrate.
    • Agree which Acceptance Criteria will be demonstrated.
    • List any issues the story raises.
    • Prepare links and handover to the next story/presenter.
  3. Agree the optimum running order (i.e., the best order for the audience).
  4. Agree the overall narrative (e.g., how the Showcase demonstrates that the iteration has met its goals).
3Rehearse Product Owner.
  1. Confirm that the Product Owner is prepared for the Showcase.
4Introduce the session.
  1. Before the demonstration begins, set up and check the space, necessary equipment, participants, etc.
  2. At the start of the Showcase:
    • State the purpose of the Showcase.
    • Explain that it’s a collaborative workshop where participants are expected to be actively involved, not observe passively.
    • But also explain that it is not a forum for accepting or rejecting the working software being showcased.
      • User acceptance has already taken place, in the form of the participating user’s agreement that the story has been implemented acceptably.
      • If Showcase participants have reservations, they should be raised via new stories in the Backlog.
    • Prompt the stakeholders for their priorities and concerns, and write them up on a whiteboard or other visible location.
  3. Explain which stories will be demonstrated and which will not (and why not).
  4. Hand over to the first demonstrator.
5Demonstrate stories.
  1. For each story:
    • Read out the story, including the Acceptance Criteria.
    • Walk through the software in such a way that the story is demonstrated and the Acceptance Criteria are tested.
    • Review any obstacles or events that substantially affected that story’s implementation.
    • Ask for feedback, suggestions and other comments.
6Review remainder of release
  1. Review the remaining iterations in the release, including:
    • Features and key stories – especially new and changed items.
    • Timeline.
    • Budget & resourcing.
    • Issues & risks.
  2. If this is the final (development) iteration in the release, review the next releases.
7Close the meeting.
  1. Check all items on the list of participants’ concerns have been addressed.
  2. Repeat:
    • Participants’ requests and suggestions.
    • Agreed actions, changes, issues, etc.
    • New or changed stories.
  3. Close the meeting.
8Update backlog.
  1. Based on feedback from the Showcase, update the backlog (at the appropriate level – iteration, release, product).
  2. Familiarise the team with any changes.

Detailed process

#StepByOutputInstructionsNotes
1Schedule the meeting.Iteration Lead.

Team.

Product Owner.

Stakeholders.

  1. During Iteration Planning, agree an approximate time for the Showcase.
  2. Schedule the meeting.
2Rehearse team.Team.
  1. Shortly before the scheduled time, rehearse the Showcase with the team members who will be actively involved:
  2. For each User Story:
    • Walk through how you plan to explain it.
    • Check the timing, including any options you plan to demonstrate.
    • Agree which Acceptance Criteria will be demonstrated.
    • List any issues the story raises.
    • Prepare links and handover to the next story/presenter.
  3. Agree the optimum running order (i.e., the best order for the audience).
  4. Agree the overall narrative (e.g., how the Showcase demonstrates that the iteration has met its goals).
  • Rehearsal is fundamental for inexperienced presenters.
3Rehearse Product Owner.Iteration Lead.

Product Owner.

  1. Confirm that the Product Owner is prepared for the Showcase.
 Verify that the Product Owner is comfortable with:

  1. The User Stories that will be included in the Showcase.
  2. The Acceptance Criteria that will be demonstrated.
  3. If needed, the reasons why any iteration stories have been omitted.
  4. Any issues the team would like to raise with the stakeholders during the Showcase.
  5. How the Showcase will be led.
  6. Their own role if the Showcase (i.e., as master of ceremonies, team champion, business representative, etc.)
4Introduce the session.Product Owner.
  1. Before the demonstration begins, set up and check the space, necessary equipment, participants, etc.
  2. At the start of the Showcase:
    • State the purpose of the Showcase.
    • Explain that it’s a collaborative workshop where participants are expected to be actively involved, not observe passively.
    • But also explain that it is not a forum for accepting or rejecting the working software being showcased.
      • User acceptance has already taken place, in the form of the participating user’s agreement that the story has been implemented acceptably.
      • If Showcase participants have reservations, they should be raised via new stories in the Backlog.
    • Prompt the stakeholders for their priorities and concerns, and write them up on a whiteboard or other visible location.
  3. Explain which stories will be demonstrated and which will not (and why not).
  4. Hand over to the first demonstrator.
5Demonstrate stories.Team.
  1. For each story:
    • Read out the story, including the Acceptance Criteria.
    • Walk through the software in such a way that the story is demonstrated and the Acceptance Criteria are tested.
    • Review any obstacles or events that substantially affected that story’s implementation.
    • Ask for feedback, suggestions and other comments.
  • Showcases are not formal acceptance events.
6Review remainder of releaseTeam.

Product Owner.

Iteration Lead.

Stakeholders.

  1. Review the remaining iterations in the release, including:
    • Features and key stories – especially new and changed items.
    • Timeline,
    • Budget & resourcing.
    • Issues & risks.
  2. If this is the final (development) iteration in the release, review the next releases.
7Close the meeting.Product Owner.
  1. Check all items on the list of participants’ concerns have been addressed.
  2. Repeat:
    • Participants’ requests and suggestions.
    • Agreed actions, changes, issues, etc.
    • New or changed stories.
  3. Close the meeting.
Questions to the audience might include:

  • Is this what you expected?
  • Does it cover the full scope?
  • Does it work as you want?
8Update backlog.Iteration Lead.

Team.

Updated backlog.
  1. Based on feedback from the Showcase, update the backlog (at the appropriate level – iteration, release, product).
  2. Familiarise the team with any changes.

Issues & risks

What are the key concerns in making a success of this practice?

  1. 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.
  2. 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.
  3. 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).
  4. Never present ‘rigged’ functionality, (e.g., hard-coded values) as working software.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?