Locked lesson.
About this lesson
The first portion of the Sprint Planning meeting consists of selecting the Sprint Backlog and clarifying Stories.
Exercise files
Download this lesson’s related exercise files.
Sprint Planning – Part 1.docx60.7 KB Sprint Planning – Part 1 - Solution.docx
60.8 KB
Quick reference
Sprint Planning – Part 1
The first portion of the Sprint Planning meeting consists of selecting the Sprint Backlog and clarifying Stories.
When to Use Sprint Planning – Part 1
When each Sprint is about to begin, the Scrum Master, Product Owner and Scrum Team gather for the first portion of the Sprint planning activities.
Instructions
- The Sprint Planning is divided into two parts with different purposes. Part 1 is to determine the Stories in the Sprint Backlog.
- The Sprint Planning Part 1 session should be attended by the Scrum Master, Product Owner and all the Scrum Team members.
- This is often the first meeting of the Scrum Team Members as a team.
- The Product Owner and the Scrum Team work together to agree on the Stories in the Sprint Backlog, the Scrum Master facilitates the meeting.
- The Product Owner starts with the Stories that he or she would like to have in the Sprint.
- Epic Stories are divided into Chapters.
- Epic stories are very large Stories. They are divided into a set of smaller “Chapter” Stories, each of which is recorded on a Story Card.
- Infrastructure Stories are added.
- Infrastructure Stories are activities and deliverables that the Scrum Team must do in order to complete the Stories from the Product Backlog.
- These often involve the acquisition, setup and testing of development or infrastructure assets such as test stations.
- These may also involve the completion of compliance activities that are not identified on a Product Backlog Story, but are required by standards such as a supplier audit.
- The Sprint Backlog Priority is set by the Product Owner, recognizing that Infrastructure Stories must be completed in time to support whatever other Story they are related to.
- Story sizing is then done.
- Stories are sized and the velocity measure is used to determine how many Stories should be in the Sprint Backlog. Stories not selected for the Backlog are still on the Scrum Board in the not selected column.
- Purpose of sizing is the improve understanding of the work of the Story and to establish a reasonable goal for the minimally viable product that is delivered at the end of the Sprint.
- The sizing is a judgement call by all Scrum Team members to estimate the amount of effort needed to complete a Story.
- When sizing a Story, the Story and Demo Criteria are read (usually by the Scrum Master) and the Scrum Team asks for clarifications from the Product Owner if needed.
- A rather small and well understood Story is selected first and used to calibrate the sizing. Once all Scrum Team members understand the Story, a size is assigned to it (usually a mid-range size) and all other stories are compared to the reference story.
- Each team member estimates the size of each Story by comparing it to the reference story and selecting an appropriate size:
- T Shirt size: small, medium, large, extra-large, too big)
- Doubles (1, 2, 4, 8, 16, 32, …)
- Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, …
- If team members disagree by more than two sizes, then the story is discussed in more detail until the team reaches an agreement.
- Once all sizing is done, the total of the sizes is added together and the velocity measure is used to determine how many Stories will likely be accomplished.
- The Sprint Backlog is reviewed to be certain that it creates a minimally viable product for the Sprint Demo. If not, the Stories selected for the Sprint are re-evaluated.
Hints and Tips
- This can become an intense meeting when there is a sharp difference of opinion on Story sizing and neither person wants to change. The Scrum Master must facilitate these situations. I recommend that when that happens, have the Product Owner and possibly another Scrum Team member talk through the Story to identify where the differences are.
- It is important that Scrum Team members agree on the reference Story and set a size for it. Some people have tendency to make everything small and other to make everything big. Setting the standard for “large” story and an “8” story will help to counter-balance that effect.
- Ensure the Scrum Team has identified all Infrastructure Stories. When there is a large sizing difference, it is often because one team member is assuming infrastructure work must be done and another team member is assuming it is in the Infrastructure Story.
- A new Scrum Team with team members who have not done this before will have often struggle with this activity since it is so different from typical project management activities.
- 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.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.