Zen of Scrum: Sprint Planning

Every sprint begins with a planning activity. This is when the Scrum team decides on the work to be done in the iteration ahead.

Sprint planning is divided into two parts.

During the first part user stories are analyzed, evaluated and estimated. After that, the developers determine a reasonable workload that they think they can commit to.

During the second part, selected stories are analyzed in more detail by the developers (remember, I use the term developer for everyone building the product, including coders, designers, testers, documenters, and so on).

How long the sprint planning takes is of course individual from team to team. A good rule of thumb is to timebox each part to the same amount of hours as the length of the sprint in weeks.

For example, a two week sprint would render a four hour meeting (two hours for story selection, and two for task break-down).

At the end, the developers commit to a number of stories and – equally important – to the sprint goal.

Part One: Selecting the Stories

So, during the first half stories are selected.

At the beginning of the sprint planning, the product backlog should already be ordered and contain enough stories that are sized correctly.

Selecting, in this context, means figuring out what the developers can commit to. The first step is to estimate the top priority stories.

It is possible, and perfectly all right, that the order of the user stories change during the meeting. Perhaps it turns out that one of the stories need to be analyzed further, or dependencies come to light as stories are discussed.

Preferably as many of these findings as possible are discovered during backlog grooming (which I will discuss in the next post).

Together with the team, the product owner can also decide if other work should be conducted, for example bug fixing or efforts to reduce technical debt.

The Scrum team should also formulate a sprint goal: a high-level goal that defines the success of the sprint. This can be pretty much anything, but I think it helps if it’s catchy and builds a “Let’s do this!” feeling.

Part Two: Identifying Tasks

During the second half of the meeting, developers work together to break stories down into tasks. At this point, the product owner does not have to attend but should still be available to answer any questions.

While user stories are fine for course-grained estimations, and for release planning, they usually don’t cut it in order for the team to commit to a sprint. Neither are they sufficient for monitoring sprint progress.

Some teams think it’s unnecessary to break stories down into tasks.

While there might be many reasons for this, I think one is that new teams tend to overdo it.

It is important. However, don’t overanalyze each task or have everyone give an estimate for each.

One good approach is to do this in front of a whiteboard, with post-its. Have everyone add and estimate tasks, pretty much like a brainstorming session. If someone thinks an estimate is off, discuss that task: either as a pair, or the whole team.

When estimating tasks, I find it effective to use a scale the same way as with user stories. For example, tasks can be estimated to 0, 1, 2, 4 or 8 ideal hours. Estimate effort, not calendar time!

Another approach could be to estimate tasks in pair. However, I like to involve the whole team as long as it doesn’t mean overanalyzing or extended discussions about estimates.

Preferably one task shouldn’t take more than one work day to complete. If you keep the tasks small, most of them are completed by the next daily stand-up. Progress becomes tangible which, if nothing else, is motivating for the team.

Another point to remember is that tasks may very well be added, or broken-down further, during the sprint.

At the end of the second half, the team should have a sprint backlog (a number of user stories, tasks for each story, and a sprint goal) that they can commit to.

---

That’s the sprint planning.

Next time I’ll write about product backlog grooming. In the meanwhile, don’t forget to checkout the slideshow at SlideShare.net.