Sprint Planning Recipe

The purpose of Sprint Planning is to create a plan for the Sprint. The entire Scrum Team attends as well as anyone they deem necessary to help them. While there is a maximum of 8h for this event, the greater the degree of understanding that the Scrum Team has going in, the shorter it will be. That is, if the Product Backlog is well understood and the Product Goal is clear, then the Sprint Planning will be short. If the Product Backlog is not well understood or the Product Goal is not clear, then the Sprint Planning will be longer.

I would expect a typical Sprint Planning to take from 30-120 minutes if there is a clear understanding.

See Professional Sprint Planning for a more detailed description of the practice.

What is a recipe?

This recipe serves as an example of how to run a Sprint Planning.

An example flow for a Sprint Planning

When designing a flow, it is hugely important to be clear on the purpose. For the Sprint Planning, the purpose is to inspect the Product Backlog, taking into account your Definition of Done and Team History, and craft a Sprint Goal, Select backlog Items, and an implementation plan for at least the first 24h.

Sprint Planning is about answering the question: “Based on the Product Goal and the current Product Backlog what can we tactically do to make progress?”.

Overview of Flow for Sprint Planning

This workshop leverages a simple flow and consists of the following:

The Product Owner presents the Product Goal, and the Scrum Team reviews the draft Sprint Goal. The Scrum Team then collaborates on selecting a Sprint Goal before then selecting the Backlog Items for that Sprint. Other than feedback from the previous Sprint Planning there should be few surprises and the expected work should be sized appropriately and ready for the Scrum Team to pull.

Once the Scrum Team has a Sprint Backlog they should ask themselves “Do they feel, as a team, that there is a reasonable degree of certainty that they can achieve the Sprint Goal?”

Although Scrum Masters can certainly facilitate the Sprint Planning, there is nothing holding others back from facilitating. Since Sprint Planning is particularly important for the Developers, as they will be doing the work, it makes sense for them to also play a role;

Suggested Flow Steps

Part 1: Product Owner Presents Product Vision, Product Goal, and possible Sprint Goals [~5 mins]

This sets the scene and focuses the Scrum Team on the purpose of the event.

Part 2: Create a Sprint Goal [~5 mins]

Use the Sprint Planning to make the Sprint Goal clear with “ Nine Whys ”. Sentences that help write clear purpose statements are “This Sprint exists in order to”, or “This Sprint exists to stop…”, or “When we achieve this Sprint Goal, what has clearly changed or improved from the perspective of stakeholders?”.

Facilitation Options

• Discuss and Agree on a Sprint Goal [5 min]
• Nine Whys [30 min]

Part 3: Select Backlog Items [~60 mins]

• Step 1: Review the current Throughput Run Chart & Monte Carlo How Many - This will give the team an indication of the number of items that they can expect to deliver during this Sprint.

• 

• Step 2: Review Team Capacity for this Sprint - Take into account vacation, as well as known pre-booked events

• Step 3: Select Backlog Items for the current Sprint Goal - Try “Min Specs” to help the team discover the essential work for this first day of the new Sprint. The Sprint Backlog, as defined during Sprint Planning, can be considered as the ‘Max Specs’: all the work, currently known, necessary to achieve the Sprint Goal.

Facilitation Options

• Select from the Product Backlog [60 min]
• Min Specs Liberating Structure

Part 4: Create Actionable Plan for 24h [~120 min]

This is where the Scrum Team creates their actionable plan for at least the first 24 hours of the Sprint. It is recommended not to assign items, and instead to identify the work and create a pull system for that work.

Facilitation Options

• Create a Plan [120 min]

Part 5: Clear communication to Stakeholders [~5 mins]

After the Sprint Review , the Scrum Team should have a clear understanding of what they will be working on, and what they will be delivering. This should be communicated to the stakeholders.