Sprint Planning – Part 2

Quick reference

• 00:04 Hello, I'm Ray Sheen.
• 00:05 Well we've talked about the first part of the sprint planning meeting,
• 00:08 now it's time to talk about the second part.
• 00:12 We're moving from the big picture planning in part one of the sprint planning meeting
• 00:16 Into a more detailed look at the work.
• 00:18 Recall that in part one, we organized the Sprint backlog and
• 00:21 incorporated the infrastructure stories.
• 00:24 Our focus in part two of the Sprint planning meeting
• 00:26 is to establish the estimates we will use to initialize the project.
• 00:31 In order to do this, we must get into detailed planning and
• 00:34 estimating of each of these stories.
• 00:36 We start with this detailed planning by deploying the stories into a series of
• 00:40 task.
• 00:41 Now small simple stories may only have one or two task.
• 00:45 However, larger more complex stories could easily have eight to ten task.
• 00:49 I recommend that you try the size of task to something that you could complete with
• 00:53 in a half of day to a day.
• 00:56 That way the whole team will quickly understand if a team member is having
• 00:59 trouble with a task, if they are still working on it for a second day.
• 01:04 Each task is estimated in days or hours of effort.
• 01:08 Notice I did not say duration.
• 01:10 If we doubled the number of people on the tasks, it will properly get done faster.
• 01:15 So the focus is on effort.
• 01:17 Not start dates and end dates.
• 01:20 Normally the product owner does not participate in this part of Sprint
• 01:23 planning, primarily because they have nothing to do.
• 01:26 The Scrum Team members are developing stories into the tasks and
• 01:30 creating estimates for each task.
• 01:32 The only thing for
• 01:33 the product owner to do is to answer any questions that may come up.
• 01:37 What I found is that some product owners can't sit back and wait for question.
• 01:41 They jump in and try to tell the scrum team members how to deploy a story and
• 01:45 how long each task will take.
• 01:47 This is not their role, so if they can't just sit back and wait for
• 01:51 questions, encourage them to go do something else.
• 01:54 But be near their desk or phone so
• 01:56 that if a question comes up they can answer it quickly.
• 02:00 Let's dig a little deeper into task planning.
• 02:03 Stories are deployed into a set of tasks
• 02:05 that comprise all the work needed to completely the story.
• 02:09 If there is design testing and
• 02:10 documentation that must be done there are tasks for all of these parts of the story.
• 02:16 A best practice used by many scrum teams.
• 02:18 They're working on technology-focused Agile/Scrum projects
• 02:21 is to use Test Driven Design or TDD.
• 02:24 This is a design approach that embeds continuous testing in the development.
• 02:29 In fact, it starts with the test requirement And
• 02:31 the design is based upon passing the test.
• 02:34 That is an action and implementation oriented approach to design and
• 02:38 development that is very compatible with the Agile/Scrum mindset.
• 02:42 A benefit this approach is that when a design task is done,
• 02:46 there's no uncertainty about whether or not it works.
• 02:49 Unlike some other approaches, Where designers create their design, and
• 02:52 then the result is handed off to another organization for tests and evaluation.
• 02:57 In this case, the designer is continually testing, as he or she is designing.
• 03:02 This type of approach, is much more likely to generate
• 03:05 a minimally viable product at the end of the sprint.
• 03:08 Even if all of the stores are not completed,
• 03:10 the ones that are have been thoroughly tested and are ready to go.
• 03:15 Every story must be deployed into tasks and the tasks estimated.
• 03:19 Normally the scrum team members volunteer to do that work
• 03:22 as each member identifies which stories they will deploy and estimate.
• 03:26 But often there are one or two stories that no one wants.
• 03:30 Either because they are difficult or awkward to work on or
• 03:33 because no one feels expert enough to estimate the story.
• 03:36 However, it must be deployed and estimated.
• 03:39 As a scrum master, what I have done, in that case is to ask two or
• 03:43 three people to work together on the deployment and estimating.
• 03:46 The task does not seem so daunting when someone else is helping.
• 03:50 When the scrum team members are estimating that amount of that
• 03:53 they need to be considering the experience and skill of the Scrum Team members.
• 03:58 That is why often team members will estimate the stories they want to work on,
• 04:02 because they have a pretty good idea about how long it will take them to do the work.
• 04:06 The Scrum Team is not constrained by some formula or
• 04:09 benchmarking estimate approach from the business.
• 04:12 They can use it if they think that it helps, but the estimate is based upon what
• 04:16 that team thinks it will take for them to do the work.
• 04:19 Once the task deployment and estimates are done, the Scrum master can gather
• 04:23 everything together and initialize the Scrum Board and Burn-Down Chart.
• 04:27 And that reminds me about one more point on the task deployment and estimating.
• 04:31 Scrum team members can identify roadblocks that aren't covered during that time and
• 04:36 put them on the scrum board also.
• 04:38 That way the scrum master can get working on these right away.
• 04:41 So now the planning is done.
• 04:44 The Scrum Team has taken the time to think about the way that they must proceed
• 04:49 to accomplish the stories.
• 04:51 That identified tasks and estimated the work.
• 04:55 Now the scrum team is ready to get to work.

Lesson notes are only available for subscribers.