Scrum in practice: planning a sprint

At the beginning of each sprint the whole Scrum team needs to meet up to determine which work will be tackled in the next sprint, how that work will be delivered and, ultimately, the goal of the sprint.

The Sprint Planning Meeting

This is the first activity of the Scrum team in any sprint and is usually time boxed so that it doesn’t eat into the time needed for actually working on tasks. For a team working in 2 week sprints I would expect planning to be no more than 4 hours.

The purpose of the Sprint Planning Meeting is to reach a consensus among the team about what they’ll be delivering during the sprint. During the meeting the team finalises the user stories that the team will work on during the sprint and normally break these user stories down into tasks.

At the end of the meeting a sprint goal will be agreed and the meeting will have generated a sprint backlog.

A typical sprint planning meeting

The Sprint Planning Meeting usually kicks off with the Product Owner talking through the highest priority stories in the product backlog – those which are in contention to make it into the sprint.

These should meet the teams definition of ready (they may have already have been talked through at a Product Backlog Refinement Meeting) and they will ideally have been estimated.

Where there has been no backlog refinement meeting the Product Owner should come prepared to talk about more stories than they anticipate will fit into a single sprint: it may be that the team will not be able to accommodate some user stories – due to whether they meet the definition of ready or the team’s capacity – and other stories will need to be dropped in to replace them.

For the team the Sprint Planning Meeting is a chance to ask any questions of the Product Owner that are necessary to fully understand the user stories and to break them down into tasks that they can actually start work on. It’s an opportunity to work collaboratively to decide who’ll be working on which tasks and also to raise any objections – to point out stories which they feel can’t be started.

Agreeing on a sprint backlog

Different Scrum teams will work out their capacity in different ways but the team together has to decide on how much work (how many stories) they’re able to take on in a given sprint i.e. how many stories are moved from the product backlog to the sprint backlog. The Product Owner can’t decide this for them, even though the PO might have very strong thoughts on it. It’s the ScrumMaster’s role to ensure a consensus has been reached by the end of the time-boxed planning meeting.

The team’s commitment to getting the work of the sprint backlog done is a fundamental part of Scrum.

One way of doing this is to allocate tokens (e.g. poker chips or matches) to each team member to represent the number of hours they have available in the sprint. The team members then place an appropriate number of tokens next to each task they will work on as the tasks are determined. When nobody has any tokens left, the team is unable to take on any more stories.

When I’m working with teams that are relatively new to Scrum I tend to create a capacity in hours based on the number of hours in a productive day multiplied by the number of days available from the team.

However I’ve worked with teams that don’t do any estimating at a level lower than the user story.

The sprint goal

The sprint goal is a one- or two-sentence encapsulation of what the team has agreed to achieve during the sprint. Some examples of a sprint goal:

• Develop a registration form with validation inline and on submission
• Build a responsive homepage with navigation menu and Twitter feed

The sprint goal is set by the Product Owner and it should encapsulate the bulk of the work in a sprint without requiring all stories to be completed for the goal to be reached.

Picture credit: “PressureSensitiveStartingBlocks” by Andrew Hecker