How to Run a Sprint Planning Meeting in Scrum: A Template for Success

Introduction

Scrum is an agile framework that helps teams work together. It encourages teams to learn through empiricism, meaning they learn via experience and observation. Scrum also encourages people to self-organize while working on a problem and reflect on their wins and losses to continuously improve. One of the key ceremonies in Scrum is the Sprint Planning Meeting. In this blog post, I will guide you on how I run my own Sprint Planning meetings to make them as successful as possible.

What is a Sprint Planning Meeting?

A Sprint Planning Meeting is a meeting where the Scrum Team decides what they will work on during the upcoming Sprint. Primarily, the Product Owner and the Developers collaborate to define a goal for the Sprint and select the Product Backlog Items that will help achieve this goal. The Scrum Master will facilitate this meeting as needed.

The output of the Sprint Planning Meeting is the Sprint Backlog. Download my free Sprint Backlog Excel template, complete with basic and advanced video tutorials!

Product Backlog Refinement

I often see Scrum teams enter Sprint Planning unprepared. An indicator of this is when a team is surprised or not aware of what the Product Owner is asking for. This is an indication of a team that is not doing Product Backlog Refinement as effectively as possible. As illustrated in my Two-Week Sprint Timeline diagram, the Product Owner and the Developers should meet once-per-Sprint to review items in the Product Backlog. This should entail estimates for new user stories, re-estimates for existing user stories once more information is discovered, breaking down user stories, and identifying any potential risks that may prevent a Scrum team from executing work in a future Sprint. If this meeting is done well, there should be little to no surprises in the Sprint Planning Meeting.

A Template to Run a Sprint Planning Meeting

1. Set the Sprint Goal

The Product Owner proposes a goal for the upcoming Sprint. This goal provides a shared objective and guides the team in their selection of Product Backlog Items.

2. Select Product Backlog Items

The Developers select items from the Product Backlog to include in the Sprint. The selection should be based on the team’s understanding of their velocity, the effort needed to complete the items, and the Sprint Goal. As a Product Owner, I will often ask for the highest priority items in the Product Backlog, and through discussion, we may identify lower priority items to bring into the Sprint.

3. Break Down Selected Items into Tasks

The Developers break down the selected Product Backlog items (usually user stories) into tasks. I coach people to ensure they can complete a single task within “one sleep”, which translates to a day or two; meaning if you start it today, you must finish it tomorrow.

4. Estimate Tasks

The Developers collectively estimate the effort required for each task. Do not ask the subject matter expert for their estimate and use that as the estimate, ensure the entire team agrees on the estimate of each task, as you do not know who on the Scrum team will do the task. This helps the team understand whether they have the capacity to complete the selected items within the Sprint. I have a technique in my book, The Scrum Field Guide, called Task-Poker that is very helpful for collectively estimating tasks in the Sprint Planning meeting.

5. Commit to the Sprint Backlog

The Developers make a commitment to complete the selected items within the Sprint. This becomes the Sprint Backlog.

Summary

Running a successful Sprint Planning Meeting is crucial for the success of the Sprint. By setting a clear goal, selecting appropriate items, breaking them down into manageable tasks, and making a commitment, the Scrum Team can ensure they are well-prepared to deliver value in the upcoming Sprint.

Remember, the goal of Scrum is not just to do work, but to deliver value. So, keep your focus on the Sprint Goal, and let that guide your planning process.