Sprint Demonstration Planning

Quick reference

• 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.