Sprint Planning – Part 1

Quick reference

• 00:04 Hi, this is Ray Sheen.
• 00:05 Let's dig into the weeds for a few minutes and
• 00:07 talk through what should happen in the first part of a Sprint planning meeting.
• 00:13 Contrary to what some critics claim, a Sprint is not chaos.
• 00:17 It is very organized.
• 00:18 That organization starts with the Sprint planning meetings.
• 00:22 This meeting is often divided into two parts,
• 00:24 because there are two different objectives.
• 00:27 In this session, I will address the first part, in the next session,
• 00:30 I will discuss part two.
• 00:32 The result of the first session is the selection of stories for
• 00:35 the Sprint Backlog.
• 00:37 The Product Owner comes to the meeting with their desired list but
• 00:40 the Scrum Team must agree with the list.
• 00:42 The Scrum Team can't reject something just because they don't like it but
• 00:46 they can ask for clarification and there may be too many items on the list.
• 00:51 Some of the stories on the Product Owner's Backlog list may be epics.
• 00:55 That means the story is very large, and really needs to be divided into smaller
• 00:59 chapters so that the work is more manageable and better understood.
• 01:04 The Product Owner and Scrum Team work together to define the chapter stories.
• 01:08 The Scrum Team will also identify infrastructure stories at this time.
• 01:12 In fact, let's look a little closer at those stories.
• 01:16 Infrastructure stories are very important to the success of the project, but
• 01:20 they were not in the Product Backlog.
• 01:22 The stories that the Product Owner has in the Product Backlog
• 01:25 are those identified by stakeholders.
• 01:27 We've talked about those quite a bit.
• 01:30 However, for
• 01:30 project work to be successful, often other activities must be done.
• 01:35 The team may need to purchase some equipment and
• 01:37 set it up in order to do testing and analysis.
• 01:39 The team may need to complete audits or
• 01:41 calibration activities in order to use key suppliers or instruments.
• 01:45 These are not on the story cards that the Product Owner has but
• 01:49 they must be done and done well.
• 01:51 They are infrastructure stories added by the Scrum Team.
• 01:54 The two most common reasons for
• 01:56 these is to create a tester development system to work with, or to accomplish some
• 02:00 compliance activities that are mandated by regulation or standards.
• 02:05 The Scrum Team members must identify these because they are related to the approach
• 02:09 that the team will use to accomplish the project.
• 02:12 The Scrum Team can't use the excuse, they didn't fund us for that.
• 02:17 If there's something they need, they must write the infrastructure story, and
• 02:20 insert that story into the Sprint Backlog.
• 02:23 An interesting point on large development projects, it quite possible that an early
• 02:28 Sprint may be entirely devoted to doing infrastructure stories, especially
• 02:34 if the project is using new technology that must be installed and tested.
• 02:39 Now onto one of the most challenging elements of a Sprint planning meeting, and
• 02:43 that is sizing the stories in the Sprint.
• 02:46 The reason that the Scrum Teams sizes the stories is so
• 02:49 that the Product Owner and the Scrum Team can agree on the stories
• 02:52 that will create a minimally viable product and that can reasonably be
• 02:56 exspected to be accomplished within the time period of the Sprint.
• 03:00 Too many stories and the result is not minimally viable product.
• 03:04 Too few and the Scrum Team is inefficiently waste time.
• 03:08 But the challenge is how to size stories before the Scrum Team has had a chance to
• 03:12 do some in-depth planning and estimating.
• 03:15 The approach I recommend is that the Scrum Master reads through each story card and
• 03:19 ensures that the Scrum Team understands it.
• 03:21 The Scrum Master then asks the Product Owner and
• 03:24 the Scrum Team members to each provide a size rating.
• 03:28 If everyone is in agreement, the story and the size is well understood.
• 03:32 If there is a big difference between the ratings,
• 03:35 there's usually some confusion about the story, either what is needed or what must
• 03:39 be done, either way everyone talks about it and you check the size again.
• 03:44 This continues until you get close agreement.
• 03:47 What do I mean by size ratings?
• 03:49 It's a judgement call that's a guess about the amount of work needed to complete
• 03:53 a story.
• 03:54 There are many ways this can be done.
• 03:56 The three most common are to use the t-shirt sizing of small, medium,
• 04:00 large, extra large, and too big.
• 04:03 The next is the doubling sequence.
• 04:05 We start with the number one, and every value after that is doubled.
• 04:09 So we get a sequence of 1, 2, 4, 8, 16, 32, etc.
• 04:12 The third approach is my personal favorite
• 04:16 just because of the elegance of the Fibonacci sequence.
• 04:20 In this case,
• 04:21 the previous value is added to the current value to get the next value.
• 04:25 So the sequence is 1, 2, 3, 5, 8, 13, 21, 34, etc.
• 04:28 Use whichever approach appeals to you and your team members.
• 04:36 The way this works is that you either take one of the stories in the Sprint that
• 04:40 everyone understands well, or you pick another activity that everyone knows and
• 04:44 understands and you assign it a value from the sizing sequence.
• 04:49 I recommend that you pick a medium to small activity so
• 04:52 that the initial size story is labeled a size medium, or is a 4 or 5.
• 04:57 The Scrum Master explains to everyone that this story is the reference story,
• 05:01 and they should consider approximately how much work is in each story
• 05:05 compared to the reference story.
• 05:08 If it's half the amount of work, the size might be small, or 2.
• 05:13 If it is twice as much work, it might be a large or 8.
• 05:17 The Scrum Master asks everyone to give their estimate of size for each story.
• 05:22 If the size estimate differs by two or more levels between the lowest and
• 05:26 the highest, ask the individuals why they sized the story at that level.
• 05:31 Usually, if there is two or more difference,
• 05:33 it is because of a difference in the understanding of the story or
• 05:37 different expectations on the Demo Criteria.
• 05:40 Talk it through to get a better understanding and check the size again.
• 05:44 The goal is to get everyone within one step difference.
• 05:47 Once you have agreement, add up all your size scores and
• 05:51 using the organization's velocity benchmark, determine if you should add or
• 05:55 subtract stories to the Sprint Backlog.
• 05:58 In the first few Sprints, these values may be all over the map
• 06:01 until the team members become comfortable with the approach.
• 06:05 This will be difficult for
• 06:06 some because this is nothing like what is done in typical project planning meetings.
• 06:11 At the end of this part of Sprint planning,
• 06:12 you should have the complete Sprint Backlog.
• 06:17 The first part of the Sprint planning meeting is used to organize the Sprint
• 06:21 by selecting the stories to be done, including the infrastructure stories.
• 06:26 By this time, the Scrum Team will probably need a quick break.
• 06:29 Give them ten minutes to be back for the second part of Sprint planning.

Lesson notes are only available for subscribers.