Sprint Planning is extremely important to Scrum. Scrum attacks a project in a series of iterations called sprints during which the work gets done. It's crucial that a sprint is planned properly, which includes tasks like setting sprint goals and selecting stories. At the end of the sprint, the team is expected have a potentially deliverable product to present to the customer.

1. Setting your sights: Sprint Planning

Before starting a sprint, you are supposed to spend a day planning it. That’s a rule in Scrum — each sprint starts with a Sprint Planning session.

The idea behind this is to determine exactly which stories the team will have to work on during that sprint. Sprint Planning must accomplish these following:

• It guarantees you are much aware of what to focus on during a sprint.
• Coupled with the End-of-Sprint Review, it ensures that what the team delivers is more closely aligned with what the customer needs.
• It allows timely decision making. Combining Sprint Planning with effective story writing practices means that the product can be delivered sooner in a project.

Without Sprint Planning, the project poses potential risk of:

• A significant reduction in the attention to the priority of the work, which can result into a situation in which lower-priority work gets done in place of higher-priority ones
• A reduction in the team understanding of the work and limiting the amount of clarification that can regularly occur
• An increase in the amount of clarification during the sprint reducing team velocity and delivery of real commitments
• A lack of understanding the team burndown velocity and estimation data

Sprint Planning is a great setting for communication between all people concerned with a project, from the Product Owner to the team members. Participants in this communication should follow a few rules:

• The Product Owner shouldn’t force the team to commit more story points than the degree they feel comfortable. After a number of sprints, the team’s velocity becomes clear.
• After the team commits to the sprint, there will be no change in the makeup of the team and the sprint requirements during that sprint.
• The team can take a task and break into sub-tasks. The team may find a given task unnecessary and can cancel it. For each task added, edited, or deleted, the team discusses the reasons for the change during Sprint Review, especially if they aren’t able to complete the sprint goal.

2. Planning in Two Different Segments

Each Sprint Planning session lasts typically a full work day, or 8 hours. Each Sprint Planning session consists of two segments. Although Scrum guidelines state that Sprint Planning typically takes 8 hours and thus, is broken down into two 4-hour segments, those times can vary. Many factors affect the actual times spent in planning a sprint:

• The complexity and depth of work to be undertaken in the sprint
• How well established the team is (and have worked together)
• The length of the sprint
• The size of the team
• How well prepared the stories in the backlog are

2.1. Segment #1: Moving items from the product backlog

The first segment of Sprint Planning is focused on:

• Selecting the high-priority backlog items from the Product backlog
• Moving them to the Sprint backlog
• Defining the Sprint goal(s).

Identifying high-priority Product backlog items

The first segment of a Sprint Planning session kicks off with the Product Owner taking center stage. The Product Owner must make a prepration and set priorities of the stories in the Product backlog before the Sprint Planning session starts. He then presents the high-priority Product backlog items to the team in story format., which fosters open communication both ways between the Product Owner and the Scrum team.

Typically, it is recommended that the Product Owner prepare and prioritize about 50 percent more stories than the Sprint Planning session is expected to use. Each story should be accompanied by a set of acceptance criteria (the Product Owner should make clear what constitutes successful completion of each story).

The first segment is all about face-to-face communication between the Product Owner and the Scrum team, with the ScrumMaster acting as facilitator. This opportunity is the chance for the team to get to know what’s expected by the Product Owner in this sprint.

It’s important that each side understand the other here — especially the expectations for story fulfillment in the sprint. The team can ask many questions and offer suggestions if appropriate.

Defining the goals of the sprint

The goal of the sprint itself must also be laid out during the planning session. If you want to create what the Product Owner wants, understanding the Sprint goal and adhering to it are crucial for the team.

There may be more than one goal for a sprint, but the Product Owner is expected to limit the number of goals for any sprint to 3. Any more than, the sprint may become unfocussed.

The testers on the team ought to pay close attention to the sprint goal to make sure the iteration meets that goal and then can be adequately tested.

2.2. Segment #2: Estimating backlog items

The second segment of Sprint Planning is all about honing the Sprint Backlog and understanding the backlog items in more detail. This segment has three main purposes:

• Team hones the Stories to be delivered
• Team estimates the work
• Team commits to the work and the sprint

Bringing it all into focus: Team refines the stories to be delivered

At this point, the team takes under consideration all the Sprint goals and the stories that are to be transferred to the Sprint backlog from the Product backlog. A big issue here is whether the overall goals of the sprint can be met during the time allotted for the sprint.

The team looks through the prioritized backlog items, making sure they understand each story. Members usually break down each story into tasks within the Sprint backlog.

Each acceptance criteria for a story or a task is also transferred to the Sprint backlog. If the team feels it needs further clarification on any acceptance criteria, it may confer with the Product Owner. Acceptance criteria may also change as a story is broken down into tasks.

At the completion of this stage, the Sprint backlog has begun to come into focus, and the stories and tasks in that backlog are in place. Stories may be transferred whole from the Product backlog to the Sprint backlog if they’re clear enough and small enough in scope — otherwise, they will be broken up into tasks.

Get out your timesheets: Team estimates the work

The Sprint backlog has been taking shape, and the team must know if it’s realistic to complete the work in the time assigned to the sprint.

Estimating the time of the work is a tricky process, but a necessary one. Scrum practices depend on being efficient with times, and the closer the team can come to estimating the time all the tasks in a sprint will take, the better. Seasoned teams will be better at this than novice teams.

A preferred approach of time estimation is to use Story Points in Scrum teams. A Story Point is a unit of time-work that can be assigned to each task — typically, a Story Point is one day of work for one person but this is adaptable. Most organizations actually use relative sizing to decide story points.

In a process called Planning Poker, the team members estimate the Story Point for each story or task. That assigns a specific amount of work and time per task.

Before this stage of the planning session, team members should consider:

• How many Story Points did they deliver last sprint? This helps set a baseline of how much work can be done in this sprint.
• Are there any holidays planned for the coming sprint? This adjusts the total points a team can complete in a sprint.
• Are there any big milestones/events taking place that may affect the process? This may impact the amount of work that can be delivered.

The team then considers a sprint velocity target. The sprint velocity is the time it will take to complete the sprint, and gives an indication of the team’s development capacity. It’s very helpful here to look at a team’s historical sprint velocity in trying to plan the current sprint’s velocity. The team should not try to be too ambitious by setting its predicted velocity too high, which invites disappointment on the part of the Product Owner (and the team).

Each task is estimated for time, typically in Story Points, until the potential Sprint Velocity is reached. Usually, the team will start with the highest-priority stories and tasks first, estimating the time they will take, and then continue with the lowerpriority stories and tasks.

Some teams have each member responsible for a story or task estimate how many Story Points (or hours) that story or task will take, and then compare their independent estimates. If the estimates don’t agree sufficiently, discussion is needed.

Let’s do it: Team commits to the work and the sprint

This phase is the final step of the second segment of Sprint Planning. After the stories have been added to the Sprint backlog and the team has determined what fits into the sprint according to the velocity estimate, it’s time for the team to commit to the tasks.

Committing to the work is done on a member-by-member basis. This part of the second segment is facilitated by the ScrumMaster, who reviews each task, presenting it to the team.

When tasks are presented, team members volunteer to commit to the tasks. If more than one team member commits to a particular task, the ScrumMaster should facilitate discussion (and the task may end up being shared).

The ScrumMaster typically starts with the highest-priority stories or tasks, asking the team members to commit to each in turn, proceeding with the lower-priority items as the higher-priority items are taken.

In this way, tasks aren’t simply assigned to team members — the team members have to step forward to accept a task. This commitment process, as far as it can go, is important to Scrum. Team members should feel that they have made a choice to “own” a particular task, accepting the responsibility for it.

The commitment process aids in team autonomy, in making sure the team can take responsibility for the sprint’s tasks. Autonomy is important to the Scrum team, and letting members choose what tasks to commit to assists in the process.

Some low-priority tasks may remain uncommitted-to near the end of this stage, and it’s up to the ScrumMaster to get them committed to without simply assigning them to team members. If there are issues here, the team should discuss them; no team member should feel openly coerced to take more work than they think they can manage during the sprint.

The second segment of the Sprint Planning session ends when all stories and tasks in the Sprint backlog have been committed to.

To have additional accountability, each day consists of a stand-up meeting, or Scrum, in which team members relate what they’ve done, what they will do, and what obstacles they face. The Daily Scrum serves to keep the team coordinated and on track. More discussion on Daily Scrums can be found in Chapter 5.

The team also keeps track of its progress by plotting completed story points on burndown charts. These charts are designed to display how the team is doing on reaching their goals. Any deviation from expected velocity, as shown on the burndown charts, must be addressed by the ScrumMaster.

At the end of a Sprint Planning session, a team should be able to check off all the items in the checklist.

3. All Things Considered: The End-of-Sprint Review

When the Sprint is complete, there’s an End-of-Sprint Review meeting which the ScrumMaster, the Scrum team, and the Product Owner all attend.

The process proceeds as follows:

• The goal of the sprint is reviewed in order to verify whether the sprint has been met.
• The results of the sprint are presented to the Product Owner (and available customers).
• If everything is acceptable, the sprint velocity is calculated as a guideline for future sprints.

(to be continued)