How Do We Run Our First Iteration Demo / Sprint Review?

Premise

The Sprint Review (or Iteration Demo or …) is a meeting where the Team presents information to the (customer especially) stakeholders about the increment of work that was completed during the last Sprint / Iteration in order to get feedback about that work.

A secondary purpose of the Iteration Demo / Sprint Review is to:

  1. Provide information on the Release Plan status by showing the results of work that has been completed.
  2. Show stakeholders that the team is operating professionally and high performance, taking responsibility for their goals, commitments and the quality of their work.

Typically, the Iteration Demo / Sprint Review is held using tele-conferencing facilities so that everyone who has an interest can attend and so people who cannot attend can use a captured recording of the tele-conference to provide feedback at a later date. The Iteration Demo / Sprint Review is structured as a small set of “context setting” activities and a series of demonstrations showing the working system just completed. These demonstrations should not be confused with a sales presentation or a training session. If sales or training sessions are needed, they should be arranged in a separate meeting.

The content of a typical Iteration Demo / Sprint Review is described in the sections below. This information is relevant in the typical Sprint / Iteration where the Team wants feedback on a set a new capabilities delivered. Sometimes other information is put in place for other kinds of work. For example:

  • A Team doing pure maintenance work may not have anything to demonstrate to stakeholders, and thus no no feedback is required. The team could do an email Iteration Demo / Sprint Review in this case.
  • A Team might be working on an Inception Sprint / Iteration (sometimes called “Sprint 0”), which means progress toward a “release plan” is being reported as well as being used to determine what we have learned so far and what adjustments we need to make.
  • A Team might be working on a final Release work, which for many means that defect arrival rates, for example, might be part of the Iteration Demo / Sprint Review.

Irrespective of what the work is, a Iteration Demo / Sprint Review should be held.

Guidelines

  1. The basic rule for Iteration Demo / Sprint Reviews is simple - functionality that isn't “done” per the “Definition of Done” cannot be presented - no exceptions.
    1. Although the meaning of “done” can vary from organization to organization, it usually means that the functionality is completely engineered and could be potentially shipped or implemented.
    2. If “done” has another meaning, make sure that the stakeholders understand it.
    3. When doing the demonstration, “done” might also mean that the demonstration shown in something that is “close to the production environment.” For a product development shop, it might mean something like “Demonstrations should be performed on End-User builds running on a clean machine.”
  2. Be very careful about using a purpose built PowerPoint presentation to structure this meeting. Using PowerPoint (apart from being a potential waste of time generating the slides) typically gives the stakeholders the feeling that this is a more formal presentation, bordering on a sales pitch. This meeting needs to be different to this and so we need to be careful about signals we are sending when using PowerPoint. A better approach is just to use the artifacts that we are using to structure the demonstration. In other words, just show the Sprint / Iteration Burn-down when talking about what happened during the Sprint / Iteration, just use the Sprint / Iteration Backlog to schedule each of the demonstrations one after another and so on.

Structure

Duration: Maximum of 2 hours for a 2 week sprint (10 working days).

Who: Team and Stakeholders especially their customers, management, users and anyone else who might be interested and have feedback.

Summary Agenda

  • Set overall context
  • Demonstrate done work
  • Gather feedback

Result: Feedback captured for the Product / Release Backlog to be prioritized so that the Backlog is ready for Sprint Planning.

Sample Agenda

  • Product Owner: Review project goals, timelines, milestones
  • Scrum Master: Review Sprint / Iteration Goals, Sprint / Iteration Burn-down, and discuss team learning that took place, especially for commitments not met (see How Do We Talk About Sprint Commitments That Have Not Been Met / Done?
  • Team Members: Demonstrate functionality
    • Stakeholders: Provide feedback
  • Team Members: Show evidence using artifacts, for example, showing quality measurements
  • Product Owner: What are we thinking will be in next Sprint
  • Scrum Master: Announce planned next sprint review date
  • Scrum Master: Thank participants

Checklist

When setting up the Iteration Demo / Sprint Review meetings (for the first time or ongoing), it may be useful to have a checklist to ensure a successful Iteration Demo / Sprint Review meeting. The following is such a checklist:

  • Set up a recurring calendar event, with virtual collaboration tool (WebEx, Lync, etc) for the Iteration Demo / Sprint Review.
  • By convention, the subject line of the email should help people understand the work being looked at. For example, “Iteration Demo / Sprint Review – Team name - (Area of Focus)”.
  • Participants invited include the Team (Product Owner, Scrum Master, all team members), and the stakeholders, especially customer stakeholders.
    • Customers: The Product Owner is responsible for working arrangements with customer stakeholders. If it is the customer's first involvement in Agile, ensure they understand their role (perhaps through an “Introduction to Scrum for Customers” session) before the Iteration Demo / Sprint Review.
    • Management: In terms of feedback provided by management, in addition to direct feedback on the functionality delivered, management should also ask about initiatives that the organization is driving. For example, if there is a renewed focus on “quality” management representatives might ask the team “how do you feel about the quality of the work you have completed?”
  • Before the actual Iteration Demo / Sprint Review meeting the body of invitation for this Sprint Review should be updated with the sprint goal and the sprint backlog indicating which items were “done”.
  • The Sprint / Iteration Goal is visible to everyone.
  • The committed backlog (Sprint / Iteration backlog) is accessible and visible to everyone.
  • The Team has prepared workstations, devices, and so forth to demonstrate the new functionality.
  • This is not a sales presentation, so its not about creating slick demonstrations. Focus on what you need to show in order to get feedback. This should not take a lot of time to prepare for: hours, not days.
  • Make sure your demonstrations can help remote people as well. If you are using a virtual collaboration tool check out what it looks like on the remote session.
  • Scrum Master records the virtual collaboration session so others that wanted to see the session but were unable to turn up can review it at a later date.
  • The team presents the Sprint / Iteration results and demonstrates the new functionality, Backlog Item after Backlog Item.
  • If customers are involved, make sure that functional user stories (as opposed to technical / non-functional or environmental user stories) are demonstrated first.
  • Demonstrate the story from the customer's point of view. Treat the user story like a mini-script and start the demonstration by saying, “as a <role>, I have just done this and now want to do …”
  • All stakeholders can provide all types of feedback - comments, observations, criticisms, requests for new functionality, and so forth. This is the purpose of the review - to get feedback that is needed to make the product better. We need this data.
  • Changes to (or additions of) features may be made to the Product Backlog at this time. (Proposed changes that affect the current Release Backlog would have to be reviewed and estimated prior to committing them to the Release Backlog.)
  • If the team reports an obstacle / impediment that is not yet solved, escalate this type of obstacle / impediment to management.
  • Explain what could not be completed during the Sprint / Iteration and why (for example, the team under-estimated effort, there were interruptions to address critical customer issues, and so forth).
  • Be sure the appropriate proprietary marking appears on any documents / PowerPoint slides used in (or sent out before) the Iteration Demo / Sprint Review or that the proprietary nature of the material shown in the Review / Demo is clearly stated.
  • Make sure the virtual collaboration tool (Webex, Lynx, etc) recording has been turned on before starting the Iteration Demo / Sprint Review introductions and is turned off before any non-Review-related discussion occurs.
  • If showing the Sprint / Iteration Burn-down and other metrics takes more than ~5 minutes with any discussion expected, ask to return to this subject after demonstrations have been completed. Focus on getting feedback from the demonstrations.
  • If the team wants feedback from stakeholders on work not yet completed, make sure there is clear separation between this and demonstrations / discussion of completed work so there is no confusion on the part of stakeholders regarding the difference.

Product Owner Options

As a result of the Sprint / Iteration Review, the Product Owner has a number of options:

  • Update the Product Backlog, for example:
    • Restore and prioritize unfinished functionality to the top of the Product Backlog
    • Reprioritize the Product Backlog based on feedback
    • Remove or lower priority of items no longer needed
  • Ask for a “Release” to implement the demonstrated functionality, alone or with increments from previous Sprints.
  • Stop the project
  • Request additional resources if necessary

Challenges of a Iteration Demo / Sprint Review

Watch for these issues as you do Sprint Reviews:

  • Team demonstrates work that is not “Done”
  • Team has not shown data indicating how they managed themselves
  • Team does not demonstrate the product from a user / value perspective
  • Team does not accept feedback well; gets defensive
  • Product Owner is surprised at Iteration Demo / Sprint Review
  • Stakeholders not available for Iteration Demo / Sprint Review
  • Team uses PowerPoint to demonstrate software functions
  • Team does not show product quality metrics
  • Feedback is not going into Product Backlog for consideration
  • Great review, but nobody knows where the project is

Want to Know More?

Use the following URL for manually sending trackbacks: http://www.hanssamios.com/dokuwiki/lib/plugins/linkback/exe/trackback.php/how_do_we_run_our_first_sprint_review
what_meetings_should_we_put_in_place_for_sprints, 2016/12/23 11:07 (Trackback)
What Meetings Should We Put in Place For Sprints? Premise One the key tools that we use when we work an Scrum / agile / lean implementation is the notion of a “cadence”. See What is the Benefit of Having a Cadence of Meetings Etc? for more on why this is important. The following notes gives you some ideas of what your calendar for a team would look like for a
 
You could leave a comment if you were logged in.
  • /home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_do_we_run_our_first_sprint_review.txt
  • Last modified: 2018/06/04 08:30
  • by Hans Samios