Sprint Planning

Sprint planning, as the name suggests, is an opportunity for the team to come together and plan their work for the upcoming sprint.  The resulting plan includes: a sprint goal, a set of stories from the product backlog that the team commits to completing during the sprint, and a set of concrete, specific, tasks — estimated in hours — the team will complete to deliver each story.  The resulting plan is called the sprint backlog and is represented with stories and tasks on the sprint task board.

It is critical to start sprint planning with a well groomed product backlog.  The stories at the top of the product backlog should meet the team’s definition of ready, be well understood by the product owner, and previously sized by the team.  The product owner and team should be able to have a short 5 to 10 minute conversation about the story and gain a shared understanding of what ‘done’ looks like, and be ready to task out the story during the sprint planning meeting.

There are a couple of ways to plan a sprint: velocity based planning or capacity based planning. (Sometimes called commitment based planning.) Velocity based planning relies on the team’s historical average velocity (Velocity = # Story Points completed per sprint) to determine how much work the team can complete in the sprint.  Capacity based planning looks at the team’s available capacity — in hours — for the sprint, and tries to fill that capacity as effectively as possible without over or under-committing.  Capacity based planning acknowledges the normal variation in the velocity from sprint to sprint.

Capacity based planning is the better approach for three main reasons:  First, not every sprint is an average sprint.  The team’s capacity is likely to vary from one sprint to another based on vacations, holidays, or other commitments.  Secondly, story points and velocity are useful measures for projecting release dates across multiple sprints, but are too course grained for planning the details of a two week sprint; hours are fine grained enough to be useful for estimating concrete tasks. Lastly, tasking the stories in sprint planning forces the team and the product owner to discuss each story in enough detail to truly develop a shared understanding of what ‘done’ looks like.

Sprint Planning Meeting

The sprint planning meeting takes place on the first day of the sprint.  The whole team attends the planning session, either physically or virtually — with a strong preference for being in the same physical space.  The Scrum Master facilitates the meeting and works through the following steps:

  1. Calculate the team’s capacity, in hours, for the sprint.  The team members report how many hours they will be available to work on sprint backlog items during the sprint — removing any time off, vacation days, or time they must spend working on non-product related work.  It is best to use a maximum of 7 hours of productive time per person per day to account for standard non work time and unavoidable distractions.The scrum master totals the team member’s available time, then subtracts the time scheduled for daily standup meetings, sprint planning sessions, sprint review, and the retrospective.  The resulting total will be the team’s available capacity.  Note: It is often helpful to group the total time available per skill set (e.g., Development and QA) when there is limited versatility across the  team.
  2. The product owner suggests a goal for the sprint and highlights a set of candidate stories from the product backlog that support reaching the goal.
  3. The team considers the highest priority story from the product backlog, reviews the story with the product  owner, identifies any additional acceptance criteria needed and develops a clear understanding of what the “done” looks like for the story.The team creates and estimates the set of tasks needed to complete the story and meet the teams definition of done.  As each task is identified and estimated, the team adds that task to the task board as either physical post-it note or virtual task in an agile process management tool.

  4. The scrum master totals the number of task hours estimated to complete the story and  subtracts the total time for that story from the total team time remaining.

  5. If there is remaining team capacity and team thinks they can commit to completing the next story, the team goes back to step 3 – and selects the next highest priority story from the product backlog.  This continues until the team can’t commit to finishing any additional stories in the sprint.
  6. At the end of the sprint planning session, the team has a plan for the next sprint represented by the sprint backlog and represented on the sprint task board.
  7. With the plan for the next two weeks in place, the team can get started working. The team conducts a stand-up, coordinating who is going to work on which tasks, and gets started.

Task Board

The sprint task board is a great way to provide visibility and focus to a sprint.  With a task board, the team can quickly see what is going on, who is working on which tasks, and how each story is progressing over the course of the sprint.  The task board also provides a focal point during the daily stand-up allowing the team to better coordinate their work and quickly identify and add any additional tasks found during the sprint.