How to run Sprint Planning

Stephen Waring
Feb 20 · 5 min read
A Scrum Team performing Sprint Planning

I have to admit, as a Scrum Master, I struggled with this for a while, so I’m hoping it helps other Scrum Masters and teams out there get started.

If you are just starting out in Scrum and are not sure how to start running this meeting at all, or would like to update the way you are running it based on the November 2020 Scrum guide updates, then take a look on how you can have an effective Sprint Planning session.

Key Facts

From the Scrum Guide:

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.

This ritual is split into 3 main parts:

Why is this Sprint valuable?

I often find it’s best for the Product Owner to walk the team through the roadmap here; describing where we are heading as a team in the long term, what the next Product Goal is, and how the Sprint we are currently planning fits into all of that.

It helps create alignment and build a vision. Reminding us all why we are here, rather than getting lost in busy work.

We also start thinking about a Sprint Goal at this point; the whole team collaborates to define a Sprint Goal but the Product Owner usually comes along with a general idea that we build out.

Starting with the Sprint Goal early on allows us to choose items from the Product Backlog that suit that goal. We’ve often fallen into the trap of defining the Sprint Goal after the items are selected.

What can be done this Sprint?

From the Scrum Guide:

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

We come armed with recent team metrics and performance data; combine that with your teams capacity this Sprint and we should be able to develop a great plan.

Calculating your team’s capacity is as simple as asking “how much time can each of you commit to this team for the upcoming Sprint”. So ask if anyone is on holiday, are there any public holidays, do you have other commitments this Sprint which will take time away from Sprint work? Write that down and you have your team capacity.

When you are just getting started, I often find it best to start calculating team capacity in days; e.g. “I’m in for 10 days this Sprint”. As you get better at this, you might want to move to more specific hour-based planning e.g. “I’m in for 60 hours this Sprint”. This should help you build a more accurate plan. That’s something you can experiment with to see what works for you and your individual situation.

At this point, we have our historical team performance and our capacity for this Sprint, so next up we need to figure out what Product backlog items we can try to complete (subject to our Definition of Done).

You can proceed in one of two ways; velocity-based or commitment-based planning:

How will the work be done?

Regardless of which planning method you choose from above, it’s often best to break down each Product Backlog item into sub-tasks, each task describing how the work will be done. The team then estimates in units of time, each sub-task.

Each team member can then add up all of the estimates for all of the sub-tasks assigned to them to check it doesn’t exceed their total capacity for the Sprint.

Summary

To wrap up the Sprint Planning session, check with the team that they all support “the plan”. By the end of this ritual you should have completed the following:

The result of Sprint Planning is the formation of the Sprint Backlog:

From the Scrum Guide:

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Agile Batman

Real life examples from a Scrum Master on how Scrum can be used to build great products

Stephen Waring

Written by

I’m an energetic and enthusiastic Scrum master who loves music, cars, computers and helping other people succeed!

Agile Batman

Real life advice and examples from a Scrum Master on how Scrum can be used to build great products

Stephen Waring

Written by

I’m an energetic and enthusiastic Scrum master who loves music, cars, computers and helping other people succeed!

Agile Batman

Real life advice and examples from a Scrum Master on how Scrum can be used to build great products

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store