The Why, What and How of Sprint Planning

I start my day with a pack of sticky notes to jot down the work, one sticky note per item, and then think of what would be the overall goal of my day. When the scrum team starts a sprint, they plan the sprint. This event is called Sprint Planning. Let’s explore how the scrum team plans a sprint. A sprint planning event is up to 8 hours for a one-month sprint.  The input to the event is an ordered product backlog, past performance of the team, and the capacity of the developers for the sprint.

The product backlog consists of items in the product backlog (Product Backlog Item). The product backlog item can be features, user stories, technical tasks as well as bugs. The top of the product backlog contains items that will deliver the maximum value to the customer.

The Why?

The product owner offers a set of product backlog items (PBIs) from the top of the product backlog. Typically the product owner might have an overall objective that he or she proposes.

The developers collaborate with the product owner to create a sprint goal.

What is a Sprint Goal?

A sprint goal is a single-line statement of what the customer is going to get at the end of the sprint. For example: If my family and I are going on vacation to Florida for a week to enjoy the beach Our family goal for that week would be to “Enjoy the beach to rest, relax and rejuvenate”. To accomplish this goal we will need to take an Uber to the airport. We will take the flight from the airport to Florida, we will take another Uber to the hotel, etc. These become the items we have to do in order to achieve our goal. Now if we have an issue with the flight, we will have to change our plans and potentially figure out an alternative. Perhaps take a delayed flight or drive to another airport to take a different flight or drive to Florida. In this case how I achieved the goal changed but my goal did not change.

This is exactly what a sprint goal is. It gets the team focused on a set of related tasks that deliver the goal. It’s their north star for the sprint.

The What?

Next, the developers look at the scope of the work proposed by the product owner and based on their past performance and capacity decide on how much they are going to take on. They might decide to take on less than what’s proposed if their past performance and capacity indicate they should take on less. They move the items they choose and move them from the product backlog to the sprint backlog. The sprint backlog contains the sprint goal and the items that the developers have chosen for the sprint. The sprint backlog is owned and protected by the developers

Past Performance

Past performance is the amount of work done by the developers in the past sprints. I recommend my teams consider looking at an average of their past performance over three to five sprints.  This number might change over time and so they can take on the amount based on this trend over time.

Capacity

This is the capacity of the developers available in the sprint. Some members might have time off, they might take some time for training or some other administrative tasks in their organization. So each sprint the developers should take an account of what their combined capacity is for that sprint.

The How?

The developers now design the work they have chosen and are part of their sprint backlog and break down the work into smaller tasks that the developers can self-assign and work together to deliver each item by priority.

While considering the what and the how, the developers also confirm that the sprint goal can still be met by the items they have chosen and how they plan to deliver them. The sprint backlog now contains the sprint goal, the product backlog items and the tasks along with who is doing what tasks.