Locked lesson.
About this lesson
The Sprint is initiated with a Sprint Planning Session that organizes the work, estimates the effort, and initializes the Scrum Board and Burn Down Chart.
Exercise files
Download this lesson’s related exercise files.
Step 3: Sprint Planning.docx85.3 KB Step 3: Sprint Planning - Solution.docx
355.5 KB
Quick reference
Step 3: Sprint Planning
The Sprint is initiated with a Sprint Planning Session that organizes the work, estimates the effort, and initializes the Scrum Board and Burn Down Chart.
When to Use Step 3: Sprint Planning
The first activity of the Sprint is to conduct a Sprint Planning session. This can easily take three to four hours for a two-week Sprint and may require all day for a large team and a three-week Sprint.
Instructions
The Sprint Planning session is normally divided into two parts, organizing and estimating.
Sprint Planning Part 1: The focus of this part is to get the Sprint Backlog finalized. It organizes the work of the Sprint. The Product Owner and Scrum Team play major roles in this portion of Sprint Planning.
- This session normally starts with the Product Owner providing a recommended Sprint Backlog. This must be agreed to by the Scrum Team so there is often a lot of discussion about several Stories.
- During the discussion, very large Stories – referred to as Epics – are often broken into “chapters” and a story card is created for each of these. The Demo criteria for these stories may be stand-alone or may need to be demonstrated with other “Chapter” stories. This needs to be clearly identified in the Demo Criteria portion of the Story Card.
- Many times the Scrum Team will identify other activities that must be done in order to do the work of the stories. For instance, special test fixtures may need to be designed and built to conduct a test that is part of the demo criteria for a new product. The Scrum Team will identify when there are predecessor or enabling activities needed to be able to do the work of the stories. These activities are described on Story Cards and treated as other Stories. They are referred to as Infrastructure Stories. Infrastructure Stories are always predecessor activities, so their priority must be assigned to ensure they are done before the Story they are supporting.
- Once all the stories for the Sprint Backlog are identified, the Product Owner assigns the priority for those stories during the Sprint.
- Once the Sprint Backlog is set, new stories cannot be added. New stories can be added to the Product Backlog and then included in future Sprints.
- Stories in the Sprint Backlog can be modified during the Sprint with approval of both the Product Owner and the Scrum Team. This will often occur because of technical problems or opportunities that arise during the Sprint.
Sprint Planning Part 2: The focus of this portion of the planning session is to estimate the work. The Stories are divided into tasks and estimated. At the end of this session, the Scrum Board and Burn Down Chart are initialized. The Scrum Master and Scrum Team play major roles in this portion of Sprint Planning.
- A Scrum Team member “volunteers” to do the planning for each story. Normally the Scrum Team member will first select the tasks with which they have experience. Every task must be planned by a Scrum Team member.
- A Scrum Team member estimates a Story by first separating it into tasks. A general rule of thumb is that a task should take no longer than eight hours. Therefore, if a task is in the WIP column for two Scrum Meetings, that is an indication of a problem with the task.
- Although eight hours is recommended, don’t create foolish tasks to abide by this rule of thumb. If you have a testing task that is a ten hour test, keep it as one task, don’t separate it into two five hour tasks.
- By the same token, try to avoid micro-tasks that can be done in several minutes. Aggregate the micro-tasks together into one task of several hours.
- Many times tasks will not have demo criteria, just check-off that they are complete. The demo criteria are met when the Story is demonstrated.
- Scrum Team members estimate the amount of effort required to do each task. This is normally done in hours, but could be estimated in other work units if appropriate to the task.
- As the Scrum Team members are creating tasks and estimates, they often uncover roadblocks. These are documented and placed in the roadblock column of the Scrum Board.
- When all Stories have been estimated the Story and Task cards are placed in the Sprint Backlog column of the Scrum Board. The estimates are added to create the initial value for the Burn Down Chart.
Hints and Tips
- There are several other sessions in the Scrum Master and Agile/Scrum Practitioner versions of this program that go into more detail on how to facilitate these planning sessions.
- I try to keep the two parts of the Sprint Planning session separate and will often take a short break between them just to emphasize that the focus of the meeting has transitioned.
- When there are multiple Sprints, the priority of Stories in the Sprint Backlog of the current Sprint may be different than the priority found in the Product Backlog.
- When estimating Stories, there are often several stories left until last because no Scrum Team member feels comfortable estimating the story. I recommend that the Scrum Master encourage several of the Scrum Team members to estimate that story jointly.
- I often create my tasks using Post-it notes and annotate which story they support along with a task description and estimate.
- The museum website project example results were typical for what I have seen in other Sprint planning sessions.
- Sprint Planning Part 1 – Organizing
- Infrastructure story added for responsive web platform selection and initialization.
- The Product Backlog was divided into two releases: Release 1: Priorities 1, 2, 3 & Infrastructure Story, Release 2: Priorities 4, 5, 6, 7, 8. This meant that the first release would contain what was in the old website, just with a responsive template. Release 2 would add new features and functions.
- The Epic story of “Convert current website content” was split into chapter stories for each current webpage, of which there were 15.
- The Epic story of “Add social media links” was split into chapter stories for Facebook, YouTube, Twitter, and Google+.
- Sprint Planning Part 2 – Estimating – only the first Sprint was estimated, so only Stories 1, 2, 3, and the Infrastructure. However, Story #2 was an Epic so it had already been separated into 15 Stories, each of which was in this Sprint.
- Infrastructure story is 4 tasks, each estimated to take 5 hours.
- Responsive web template story (Priority #1) was separated into 3 tasks of 4 hours each.
- The fifteen “convert content page” stories were each separated into two tasks that were estimated at 2 hours per task. These were Priority #2 and the 15 webpages were prioritized to be numbers 2.1 to 2.15
- The contact buttons and the donor button story (Priority #3) was separated into 5 tasks – each estimated at 3 hours.
- There were 18 Stories and 42 tasks on the Scrum Board.
- The total estimate of 107 hours was used to initialize the Burn-down chart.
- Sprint Planning Part 1 – Organizing
- 00:04 Hello, I'm Ray Sheen.
- 00:06 Let's now look at step 3 in the Agile/Scrum project approach for
- 00:10 Sprints, Sprint Planning.
- 00:12 The Sprint planning meeting is divided in to two parts.
- 00:15 The first is organizing and the second is estimating.
- 00:18 Let's start with organizing.
- 00:21 At this meeting the stories from the product backlog that will be addressed in
- 00:24 the Sprint and are selected and placed into the Sprint backlog.
- 00:28 The product owner will normally provide a suggested list but
- 00:31 the final backlog must be agreed to by the Scrum Team.
- 00:35 Getting the Sprint backlog right is important.
- 00:38 Once the Sprint starts, no new stories can be added to the Sprint backlog.
- 00:42 Now, these stories can be added to the product backlog but they have to wait for
- 00:45 a future Sprint.
- 00:47 The backlog for this Sprint is set.
- 00:49 Since most Sprints are only a few weeks in duration,
- 00:52 there normally is not a great push to change the Sprint backlog.
- 00:56 During part one of Sprint planning, each story is discussed.
- 00:59 Often it will become evident that some of the stories will require a lot of work.
- 01:04 They're often referred to as epic stories.
- 01:06 These stories are normally separated into chapter stories
- 01:10 to make them easier to plan, understand, and execute.
- 01:14 Another thing that occurs at this time is the Scrum Team will identify what
- 01:17 are called infrastructure stories.
- 01:20 These are activities that must be completed in order to do the work
- 01:23 of the stories listed in the Sprint backlog.
- 01:25 For instance if a story required the test is part of the demo criteria
- 01:29 the Scrum Team may need to first design and
- 01:31 build a test fixture in which two conduct the test.
- 01:34 This would be an infrastructure story.
- 01:37 The product owner is not asking for the test fixture, he or
- 01:40 she just wants to know that the project deliverable can pass the test.
- 01:44 But the Scrum team realizes the test fixture is needed first.
- 01:47 So they create the infrastructure story.
- 01:49 The priority of those stories is set to ensure that they complete
- 01:53 before the story that needs the infrastructure is prioritized.
- 01:57 If you are taken the Product Owner,
- 01:58 Scrum Master or Agile Practitioner version of this course, There will
- 02:02 be another session that discusses how to facilitate this part of Sprint planning.
- 02:07 Now for part 2, estimating.
- 02:09 This portion of the planning session is driven by the Scrum Team members.
- 02:13 They start to select, or volunteer, for the stories in the sprint backlog.
- 02:17 Each member takes at least one story and
- 02:19 determines the tasks needed to do that story.
- 02:21 Each task is noted on a card or Post-it note.
- 02:24 The Scrum Team member then estimates how many hours of work or
- 02:28 work units it will take to do each task.
- 02:31 While determining the task,
- 02:32 the Scrum Team members will often identify roadblocks that must be overcome.
- 02:36 Now a roadblock is something outside the control of the Scrum Team member.
- 02:41 Hard work is not a roadblock.
- 02:43 The roadblocks are identified,
- 02:44 are placed in the roadblock column of the Scrum Board.
- 02:47 Once a team member has estimated all the tasks and identified any roadblocks for
- 02:51 a story, they select another story from the Sprint backlog and
- 02:55 so it continues until all stories are planned and estimated.
- 02:59 When all the estimating is complete the stories and task are placed in the Sprint
- 03:03 backlog column of the Scrum board, and the roadblocks in the roadblock column.
- 03:07 The estimates are all added and the value is used to initiate the burn-down chart.
- 03:12 If you're taking the Scrum Master, or Agile Practitioner version of this course,
- 03:16 there will be another session that discusses how to facilitate
- 03:19 this part of Sprint planning.
- 03:21 Let's look at the roles, responsibilities, and deliverables.
- 03:25 I think I've already talked about all of these.
- 03:27 But one point I wanna make is that the senior management
- 03:29 does not have any responsibilities or deliverables.
- 03:33 They are not involved in the detailed Sprint planning.
- 03:36 They do not review and approve the plan.
- 03:38 It was their job to pick people they trust and assign them to the Scrum Team.
- 03:43 The team is empowered to plan and execute the Sprint.
- 03:47 Let's move onto the museum website upgrade example.
- 03:50 This will help to illustrate what happens in the Sprint Planning meeting.
- 03:53 I'll look at part one of Sprint planning first.
- 03:56 As we started to discuss the first story, which was to create a responsive web
- 04:00 template, we've realized that we've first needed an infrastructure story
- 04:04 to select and initialize a responsive web platform to work with.
- 04:08 As product owner I said that there would be two releases.
- 04:11 The first one just a straight conversion of the existing site.
- 04:15 And the second one would be all of the added functionality.
- 04:18 That meant the first release would be stories one, two and
- 04:21 three, along with the infrastructure story.
- 04:25 There were two epic stories.
- 04:27 One was priority number two, which was the conversion of all of the current webpages.
- 04:32 We separated that into the 15 chapters,
- 04:34 which represented the 15 existing webpages.
- 04:38 The second epic would actually be addressed in the second Sprint.
- 04:41 And that was to get social media sites going on all the major social media
- 04:45 platforms, then setting up links on the new website.
- 04:49 Well, onto Part 2 Estimating.
- 04:51 The infrastructure story was was four tasks.
- 04:53 Each taking about five hours.
- 04:55 The responsive web story,
- 04:57 priority number one, was separated into three tasks, each taking four hours.
- 05:02 The 15 convert current webpage chapter stories,
- 05:05 they were a part of priority number two, were prioritized and estimated.
- 05:09 Each chapter story had two tasks and each task required two hours.
- 05:14 Finally, converting the buttons for contacting the museum and donating,
- 05:18 priority number three, was separated into five tasks each taking three hours.
- 05:24 This added up to a total of 18 stories and
- 05:26 42 tasks on the Scrum board in the Sprint backlog column.
- 05:30 And 107 hours was It was used to initiate the burn-down chart.
- 05:34 A fundamental principle in project management is planning.
- 05:40 Although the planning's a little bit different when planning for
- 05:43 the Agile/Srum Sprint the principle is still true.
- 05:46 You need a plan.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.