Locked lesson.

Upgrade

About this lesson

Sprint Demonstration Planning ensures that the Sprint Demo meeting appropriately reflects the work accomplished by the Scrum Team.

Quick reference

Sprint Demonstration Planning

Sprint Demonstration Planning ensures that the Sprint Demo meeting appropriately reflects the work accomplished by the Scrum Team.

When to Use Sprint Demonstration Planning

Sprint Demonstration Planning should be done several days before the Sprint Demo to ensure that the Scrum Team and Product Owner are prepared for a productive meeting.

Instructions

  • The Sprint Demo is the primary technical review in Agile Scrum projects. 
  • A Sprint Demo occurs at the end of each Sprint.
  • The Sprint Demo is between the Scrum Team and the Product Owner, although the Product Owner will often invite other stakeholders to participate.
  • Although there is no formal role for the Scrum Master at a Sprint Demo, often that individual facilitates the meeting and takes notes of the decisions and comments.
  • The goal for the Product Owner in the Sprint Demo is to ensure that the Sprint results are a Minimally Viable Product or if it is the last Sprint in a Release that it is a Potentially Shippable Product. 
    • This implies that at least most of the functionality that was reflected on the Story Cards is completed.
    • The product has adequate functionality that it can be used for internal and possibly external testing.
  • The goal for the Scrum Team in the Sprint Demo is to show that the work they completed was done correctly and meets the Demo Criteria.
  • Recommended agenda for the Sprint Demo meeting:
    1. Introductions and explanation of the process.
    2. Overview of the design approach used and how the work was completed.
    3. Demonstrate the functionality of the product/system
      • Testing by Product Owner.
      • Testing by invited stakeholders.
      • Test the use cases or test conditions specified.
    4. Explain any Stories not completed and why.
      • Recommend Story changes for the next Sprint.
      • Recommend Story elimination and rationale.
      • Story will be considered by Product Owner in the Sprint Refinement and a disposition of each uncompleted Story will be made.
    5. Review results and answer any final questions.
  • The Scrum Team should appropriately use “Industry Standards” and “Engineering Discipline” when doing the development effort.
    • Agile/Scrum is not undisciplined chaos.
  • Standards are often embedded in the Demo Criteria.
    • Demo Criteria specifies performance based upon levels found in standards.
    • Demo Criterial cites a compliance with a particular code or standard.
    • Demo Criteria cites attainment of product certifications.
  • Design work must comply with Engineering Discipline.
    • Documentation Standards.
    • Technical practices.
  • Product/system developed must be safe and compliant to be viable and practical.

 

Hints and Tips

  • Don’t guess at Demo Criteria, if you don’t know or understand the criteria ask for clarification from the Product Owner.
  • Sprint Demo meetings can be quite short (30 minutes) of long (all day) depending upon the complexity of the product or system and the level of review that is conducted by the Product Owner and stakeholders. Coordinate with the Product Owner ahead of time to set expectations.
  • Bring the product/system and the documentation to the Sprint Demo meeting. Don’t show pictures of what you did – show the actual results. If necessary hold the Sprint Demo meeting at a location where the Product Owner and stakeholders have access to the system.
  • Many engineers and developers dislike doing documentation. Ensure the Demo Criteria clearly describes the documentation requirement. That is often a separate task for a Story. Remember the Story is not done until all the tasks are done.
Login to download
  • 00:03 Hi, this is Ray Sheen.
  • 00:06 Well I've been doing some deeper dives on several topics associated with running
  • 00:09 an agile scrum project.
  • 00:11 I'd now like to dig deeper into the Sprint demo meeting.
  • 00:14 I hope you recall the the Sprint Demonstration where it
  • 00:18 is more commonly called the Sprint Demo, occurs at the end of each sprint.
  • 00:22 This is the only technical review that is embedded as a standard part of
  • 00:26 the Agile/Scrum methodology.
  • 00:29 You could do other reviews like a PDR, or a CDR, but
  • 00:32 those will be written out on a story card and will be done as a deliverable activity
  • 00:36 within one of the sprints on a large Agile/Scrum project.
  • 00:40 The sprint demo happens no matter what, because that's where the project
  • 00:44 owner assures themselves that the project work was done, and done right.
  • 00:48 The product owner's goal for
  • 00:50 this meeting is to ensure that the Scrum team delivers a minimally viable product.
  • 00:55 Sure they would like to have all the stories completed, but
  • 00:58 even if some aren't done, the results should be minimally viable, so
  • 01:01 that they can be used to demonstrate many, if not all of the stories.
  • 01:05 That means that the story card requirements for
  • 01:08 the stories that are finished have been fulfilled and
  • 01:10 their performance is adequate for at least some internal testing.
  • 01:14 If it is the last sprint in release, then the level of expectations go up and
  • 01:19 the Scrum team needs to deliver a potentially shippable product,
  • 01:22 because this will likely be released to customers.
  • 01:25 The Scrum Team also has a goal for
  • 01:27 the Spring Demo meeting, they wanna show off what they accomplished.
  • 01:31 They literally wanna demonstrate a new product or system to the product owner and
  • 01:35 any invited stakeholders.
  • 01:37 They want to show that what they've developed lives up to the expectations,
  • 01:40 meeting the stakeholders' standards and requirements.
  • 01:43 The Scrum Team should take a few minutes a day or two before the Sprint Demo and
  • 01:47 plan how they intend to explain what they have done.
  • 01:50 Which stories are covered first, and which are last.
  • 01:53 Which ones do they encourage the product owner and stakeholders to play with, and
  • 01:56 which do the team tightly control.
  • 01:59 Incidentally, depending upon the complexity of the product or system, and
  • 02:02 the number of stakeholders in attendance,
  • 02:04 these meetings can last from a half hour to all day.
  • 02:09 In fact let's talk about how to run one of these meetings.
  • 02:12 We've already stated several times that the product owner and
  • 02:15 invited stakeholders are there as the reviewers.
  • 02:17 The Scrum Team is there as the presenters and
  • 02:20 the Scrum Master is normally there as a facilitator and notetaker.
  • 02:24 Of course, start off with introductions and if necessary,
  • 02:26 the Scrum Master should explain the purpose of process of the sprint demo.
  • 02:31 Then the Scrum Team should explain the technical approach that they use to
  • 02:34 accomplish the work,
  • 02:35 sort of like a big picture overview of what the design work is.
  • 02:39 After that get into the demo, this is where most of the time should be spent.
  • 02:44 I recommend that you review each story and demo it with an appropriate test or
  • 02:49 use cases.
  • 02:50 If at all possible, the testing or checking should be done by the product
  • 02:54 owner or one of the stakeholders, not by the Scrum Team.
  • 02:57 They're there to explain and answers questions.
  • 02:59 But nothing will convince someone else about the performance of a product or
  • 03:02 system better than actual experience with that system.
  • 03:07 After going through the stories that are done,
  • 03:09 the Scrum Team may need to also discuss some stories that they did not get done.
  • 03:14 Every story in the Sprint backlog needs to be mentioned,
  • 03:17 either in the demo section or in this section.
  • 03:20 It is common to not complete a few of the lower priority stories.
  • 03:24 I suggest for those that when you list the stories, you explain why it wasn't done.
  • 03:29 Was there a technical problem or you just ran out of time.
  • 03:32 If you have any recommendation for improving the story based upon what you've
  • 03:35 learned in the Sprint, feel free to make the recommendation.
  • 03:39 But realize it is ultimately up to the product owner whether to accept it or
  • 03:42 reject the recommendation.
  • 03:44 These stories are still part of the product backlog.
  • 03:47 So if they're not completed the product owner will likely include them in
  • 03:50 another Sprint.
  • 03:52 To close out this session, I wanna talk for a few minutes
  • 03:55 about the use of Standards and Engineering Discipline on Agile/Scrum projects.
  • 04:00 I've included the topic here,
  • 04:01 because it is at this time in the Sprint demo on these topics are most important.
  • 04:06 Some people have claimed that the Agile/Scrum projects are just designed
  • 04:09 chaos.
  • 04:10 The team can do whatever they want, and there's no engineering discipline.
  • 04:14 Not true.
  • 04:15 The teams have flexibility to do the work in whatever manner they believe is fast,
  • 04:19 and efficient.
  • 04:20 But if you put the standards in the story, and
  • 04:22 apply the engineering discipline to the demo criteria, both are still right there.
  • 04:27 If the result demands compliance to standards,
  • 04:30 Agile/Scrum projects can deliver that.
  • 04:32 The story card and demo criteria need to list the industry standards for
  • 04:36 performance, or the safety standards.
  • 04:38 Sometimes if the work is done under contract,
  • 04:40 there are contractual standards and specifications that must be met.
  • 04:44 And if a commercial product, there are typically product standards based
  • 04:47 upon the product category, and where it will be sold.
  • 04:50 All of these could, and should, be on a story cart.
  • 04:54 Also an organization can require that work be done,
  • 04:57 in accordance, with certain design or engineering disciplines.
  • 05:00 Design changes to existing products or
  • 05:02 systems must be submitted following the engineering change procedure.
  • 05:06 All commercial products must complete an FMEA analysis.
  • 05:10 Drawings must be done with a CAD system model and a geometric dimensioning and
  • 05:13 tolerancing.
  • 05:14 Software must conform with the IEEE standards and on and on it goes.
  • 05:19 The point is though is it can be done, as long as it is in the story or
  • 05:23 the demo criteria of a story card.
  • 05:25 And the reason for that is the minimally viable product or
  • 05:29 potentially shippable product must be safe, reliable and
  • 05:33 free from harms and hazards before we send it out for others to use.
  • 05:37 This is just plain common sense.
  • 05:40 So plan for your Sprint Demo.
  • 05:43 Think through how to present the results and
  • 05:46 how to describe both what was done and what was not done.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course