why_do_we_run_a_system_demo_when_we_ve_just_done_a_sprint_review_or_iteration_team_review
Why do we run a System Demo when we’ve just done a Sprint Review or Iteration (Team) Review?
For many people it seems like we are doing double duty when we run both an Iteration (Team) Review and a System Demo; aren’t they showing the same things? While there is clearly a relationship between is what being demonstrated at these events, the focus for the Iteration (Team) Review and the System Demo is different; Iteration (Team) Reviews demonstrate “done” user stories while System Demos demonstrate “done” features. This has several implications:
- While Iteration (Team) Reviews of stories could be demonstrating progress on features, they don’t show the whole feature when all the stories that make up that feature are complete. The result is that from a Feature perspective, the demo is piecemeal. The System Demo is different in that the demonstration shows the complete Feature, showing the result of work that could have come from multiple iterations and teams.
- If the work a team does doesn’t result in the completion of a Feature for a particular iteration, then their work will not be showcased in the System Demo. This means most System Demos showcase the work of a few of the teams on the train; it is a train event. This is different to an Iteration (Team) Review where teams are expected to demonstrate all stories every iteration.
- The System Demo is based on Features and their related PI Objectives which represent a business value delivered that the customers and the business is interested in. This means that a different level of stakeholders will be interested in the System Demo than those involved in Iteration (Team) Demos with a different level of feedback, and a different set of expectations.
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/why_do_we_run_a_system_demo_when_we_ve_just_done_a_sprint_review_or_iteration_team_review.txt · Last modified: 2021/11/21 10:58 by hans