STEP 11
Sprint Planning
1
FACT-
In the first half of sprint planning, the team asks questions of the Product Owner to clarify what is to be built.
The information in the Product Backlog is not detailed enough for the team to run with it. There’s still a lot of detail that must be surfaced. This is done through conversation, since Agilists believe conversation is more useful than communicating through artifacts like specs.
2
FACT-
While estimating PBI size in Sprint Planning is technically allowed, it’s best to estimate prior to planning.
While not originally outlined in the Scrum Framework, most practitioners have found that having a session of “backlog refinement” (also called “story time” or “backlog grooming”) is helpful. For a 2 week sprint, one should set aside 2 hours of refinement. It’s a good idea to schedule this mid sprint, so that the PO can do extra research/clarification prior to the next sprint planning session if need be.
3
MYTH-
The Product Owner assigns development tasks to the Team.
The team members are the only ones who decide what work gets done, and by whom.
4
MYTH-
The Product Owner is involved in figuring out how code is written.
The Product Owner is responsible for describing WHAT is to be built. The team determines HOW the WHAT is built. Only the team has the authority to figure out how to write code.
5
FACT-
In the second half of Sprint Planning, the Product Owner may be needed to help further clarify questions the team has.
Product backlog items need clarification through conversation. This can happen at any time during a sprint, though a large part of it happens on planning day, and while most issues are clarified in the first half of Sprint Planning, the team often requests additional clarification when they start digging into the items in the second half of planning.
6
FACT-
The second half of Sprint Planning is for the team to break product backlog items down into development tasks.
While the team may come up with tasks at any time during the sprint, they should do what they can to flesh out as much of the sprint backlog as possible by creating tasks for the stories to which they committed.
7
FACT-
Instead of estimating tasks in hours, some teams find it easier to count up the # of tasks for a given Sprint. They then use that number for their Sprint Burndown.
While some teams prefer estimating tasks for a story with hours, others find the extra work of low value, and instead simply count up the number of tasks they have. When trying this approach, be sure to set an upper limit of task size (hint: try a limit of 1 day).
8
FACT-
Sprint planning for a 2 week sprint should be time boxed to 4 hours.
For a two week sprint, set aside 4 hours for sprint planning: 2 hours for clarifying PBIs with your product owner, and 2 hours to break PBIs into tasks. These numbers can be doubled for a month long sprint, or cut in half for a one week sprint. Regardless of the length, the output of this meeting should be a commitment from the team to the product owner as to what will be completed in the upcoming sprint.
9
FACT-
Adding a Backlog Refinement session half way through your sprint can help with making Sprint Planning shorter and more effective.
While not originally defined in the early Scrum literature, most practitioners have found a session of Backlog Refinement (a.k.a. “Story Time” or “Backlog Grooming”) very helpful. During this meeting, the team and product owner get together to clarify and estimate stories, just as they do in the first half of sprint planning. Backlog Refinement helps keep Sprint Planning short and more effective since POs have a chance to clarify any new stories with the team prior to Sprint Planning.