Sprint Planning Playbook

Overview

Sprint Planning is the event where Teams collaborate to decide what they will deliver in the next Sprint.

It is often divided into 2 parss.

During the first part, the Team select WHAT they will deliver through visibility of their capacity and negotiation with the Product Owner.

In the second part of Sprint Planning, the Team decide HOW they will deliver what they selected in the first part, defining tasks and actions. The conclusion of the second part of Sprint Planning is a commitment to deliver all the selected outcomes and the commencement of the Sprint.

Plays

There are 6 plays in completing this Playbook:

Preparation
Review the Definition of Done
Agree the Sprint Goal
Agree WHAT will be delivered
Agree HOW the selected items will be delivered
Commit and start the Sprint

Purpose

Empower the Team to determine for themselves what they will build and how they will go about it
Enable better planning as the decisions about what and how are made by the people closest to the product
Engage stakeholders
Uplift commitment
Provide visibility of the next deliverables to be built
Enable better decision making, especially if something goes wrong during the Sprint, the Sprint Goal help you make better trade-off decisions
Enable better outcomes rather than more output

Participants

ALL Team Members
Scrum Master
Product Owner
Invited SMEs and Stakeholders

Difficulty

3 - Moderate

Duration

Timeboxed to 1-4 hours, (usually 1 hour per week of Sprint, so a 2 week Sprint would start with a 2 hour Sprint Planning.)

Materials

Team's Visual Management Board

Meetings to cancel when you set up your Sprint Planning

Detailed scope or business requirements
Checkpoint meetings
Work or task allocation
Anyting else that is about organising what the Team will deliver, Sprint Planning enables them to do that for themselves

What is a Sprint Backlog?

The Product Backog is the prioritised list of all the valuable customer outcomes we want to build into our product.

During Sprint Planning the Team select items from the Product Backlog that they will deliver in the next Sprint. Those items selected form the Sprint Backlog.

While the Product Backlog is always under review and can change at any time, the Sprint Backlog should not be changed except in extreme circumstances.

Preparation

Scrum Master Preparation

The Scrum Master prepares for Sprint Planning by assessing and making visible:

The Team's capacity, (many Teams call this their 'velocity',) including any variation such as planned leave or training
Assessment of the previous Sprint, including any work not completed within the Sprint
Engage and align with the Product Owner

Team Preparation

The Team prepare for Sprint Planning by:

Contributing to the definition of the Sprint Goal
Ensuring they are familiar with the PBIs that are candidates for the next Sprint
Ensuring the Scrum Master and the Team know of any planned absence such as annual leave or training that you have in the next sprint

Product Owner Preparation

The Product Owner prepares for Sprint Planning by:

Ensuring the Product Backlog is prioritised
Ensuring all Product Backlog Items that are candidates for the next Sprint are well refined and understood
Socialising all PBIs that are candidates for the next Sprint with all Team Members and invited SMEs and Stakeholders
Engaging and aligning with the Scrum Master
Reviewing and potentially updating the Product Roadmap to define an outcome based Sprint Goal
Working with Stakeholders, SMEs and the Team to refine the Sprint Goal
Ensuring any Stakeholders or SMEs that can provide the Team with additional context are invited and will attend

Review your Definition of Done

Before deciding what work will be completed in the next Sprint, it is important to review your Definition of Done.

Not only will this help people to remember what it means for an item to be considered 'Done', it provides an opportunity to improve the definition so it can include all your latest learning.

PRO TIP!

Review your Definition of Done any time an item is not completed within the Sprint, has defects or fails in some way to deliver the expected outcome.

Agree the Sprint Goal

The Sprint Goal is a high level outcome that the Team will strive to deliver through completing the Product Backlog Items they select for the Sprint.

If you have a roadmap of valuable customer outcomes, then the Sprint Goal will often be easy to define as simply the next highest priority outcome. Selecting and socialising the Sprint Goal in advance of Sprint Planning helps to align the Team and makes it easier to select items for the Sprint.

If complexities or difficulties emerge during the Sprint that impede the Team's ability to complete all the items they planned to deliver, then they can re-negotiate the scope of the Sprint with the Product Owner. SHould this be necessary, the Sprint Goal is enormously helpful in agreeing the trade-offs that need to be made.

The Sprint Goal should NOT be a list of Backlog Items.

From the Scrum Guide:

“It provides guidance to the Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Team to work together rather than on separate initiatives.

As the Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”

Phase 1: Agree WHAT will be delivered

Start here

With visibility of the Team's capacity and any variation due to annual leave, training or other absences, the Team and the Product Owner agree WHAT will be delivered in the next Sprint.

Based on the Sprint Goal, the Team and the Product Owner select the highest priority item in the Product Backlog that meets the Team's 'Definition of Ready'.

Usually each item requires only a brief discussion as everyone is already very familiar with it.

Phase 2: Agree HOW the selected items will be delivered

When the Team has selected the Product Backlog Items they will deliver in the next Sprint, the Sprint Backlog has been formed, but Sprint Planning is not yet complete.

Knowing the items the Team wants to deliver is not enough to have an effective Sprint Plan, for that you also need to know HOW you will deliver them.

Some Product Owners attend Phase 2 so they can contribute to the discussion relating to any trade-offs that might emerge if the Team discovers a simpler way to deliver something while they are discussing how it will be delivered, but most Product Owners and stakeholders will happily step away at this stage.

Discuss each item the Team has added to the Sprint Backlog.

How will we deliver it?

Define the tasks and actions that need to occur in order to deliver the item.

Many Teams use 'sub-tasks' so they can see the flow of smaller items during their sprint and impediments are more visible, others simply list the tasks and actions they need to complete.

Commit and start the Sprint

Once the Sprint Backlog has been formed and the tasks and actions that the Team needs to complete in order to deliver it are defined, you have a plan for how the Sprint will be delivered.

At this point, the Team needs to commit to the plan.

That means acknowledging that with the information to hand, the experience, skills and knowledge of the Team and the best intentions, we believe we can deliver what we have planned and will do everything within our power to deliver it.

That doesn't mean the plan will never change, if complexities emerge or the unexpected happens we will still have a discussion with the Product Owner about the need to change, but we'll do the very best we can to deliver on what we have planned.