Planning Your Scrum Sprints — Stage 4
The planning of scrum sprints is Stage 4 in the roadmap to value. All the work to be accomplished during that specific sprint is planned here. Each sprint planning session is timeboxed to no more than two hours for each week of the sprint. If you have a one-week sprint timebox, you have a maximum of two hours to plan your sprint, for example.
A goal is created for each sprint. The product owner initiates the goal discussion, identifying the business value objective that needs to be met. After the team is clear on the goal, the product owner chooses the requirements from the product backlog that best support the goal. As with the release goal, the sprint goal drives the requirements developed, not the other way around.
The sprint goal itself must support the release goal, which supports the vision statement. This goal decomposition and alignment are essential for ensuring that you are doing purpose‐driven development.
The development team is critical in creating the sprint goal. Because they’re the ones doing the actual work, while the product owner establishes the direction, or the “what,” the development team establishes the “how” and “how much.”
If your development team has an established average velocity, it may be used as input in determining the amount of work they will take on during the sprint.
The development team can also use velocity for stretching, testing its limits, or backing off if they’re struggling to achieve the goals set. If they’ve been achieving 34 story points comfortably, they might push it to 38 or 40. If they’ve been struggling to achieve 25, they might lower it to 23 while the scrum team figures out organizational drag that can be removed.
Both phases of sprint planning occur in the single sprint planning meeting at the beginning of the sprint. Phase I is where the product owner, with input from the development team and facilitated by the scrum master, determines what needs to be accomplished (the goal). In Phase II, the development team determines how to achieve the sprint goal and develops the actual sprint backlog of supporting tasks.
The sprint planning meeting may not always go smoothly, especially at first. You may slip down rabbit holes, discover tangents, and unearth different estimations of what’s possible. This is where a strong and deft facilitator is needed in the form of the scrum master. It’s their job to make sure that the session stays on track and the heat stays on low.
At the start of Phase I, the sprint goal is created, and the development team must fully understand it, because it will provide the boundaries and direction for the work they will do throughout the sprint. The product owner then selects a portion of the product backlog that supports the goal. This won’t necessarily be the final sprint backlog, but is the forecasted functionality that if finished in the sprint, would satisfy the sprint goal. It’s what the development team will work from to achieve the sprint goal and determine the actual sprint backlog.
Phase I gives the development team and product owner another opportunity to clarify any existing requirements or identify new ones that are needed to achieve the sprint goal. This would also be the time to give the final size estimation on any clarified requirements and size any new requirements for the sprint. Remember my yardstick: If any requirements are sized higher than an 8, they’re too big for a sprint.
I like to bring between six and ten product backlog items into each sprint. This is usually the right balance of being able to deliver a product increment with substantial functionality as well as litmus that each individual item is sufficiently broken down.
The only requirements discussed in sprint planning should be those estimated between 1 and 8 on the Fibonacci scale. This isn’t a scrum rule, but it aligns with our affinity estimating model and has been an effective way for many teams to keep focused on properly refined requirements that can be completed within a sprint.
When the goal and the supporting requirements have been determined by the scrum team, the development team breaks down those requirements into individual tasks — how they will turn product backlog items into the product increment. The tasks for each requirement should explicitly satisfy the team’s definition of done. For instance, if the definition of done includes integration with system “A,” at least one task for the requirement should be “integration test with system A.”
Ideally, each task should be able to be completed in one day. This gives the development team a tangible, realistic time target as they break requirements down into tasks. It also sets a benchmark from which the team can be alerted to any development problems. If a task is taking multiple days to develop, an issue might need to be addressed with the task or the developer.
Development teams may choose to estimate the tasks for each requirement in hours if the organization wants that level of visibility. But many teams simply use velocity and complete/not complete of product backlog items to adequately visualize sprint risk.
The development team is forced to be the most detailed here, which helps to sharpen the mind. They can really dig down and look at what needs to be done.
By the end of sprint planning, the development team should be clear on how the chosen sprint backlog items support the sprint goal and how the work to complete those backlog items will be done. This does not mean that all (or any) of the tasks on the sprint backlog get assigned at this time. Rather, each day the development team will self-organize by having each developer pull a task and work on it to completion.