Scrum Events #2 Sprint Planning

June 2, 2020 • 8 min to read

This article describes all aspects of the Sprint Planning meeting. It will help you to understand the purpose of this event, how it looks like & what you need to remember about.

Table of Contents

Introduction

*This post has been updated based on the Scrum Guide 2020

In my last post I’ve started the Scrum Events series and described the first event in Scrum - Sprint. If you haven’t read it yet, I recommend you do it before reading this article.

Today I would like to continue the series by describing the event which initiates the Sprint - Sprint Planning.

Please take into consideration that some parts of the Sprint Planning that I described are not explicitly explained in the Scrum Guide and I used examples of the common practices or my personal opinion.

Sprint Planning - definition and length

Each Sprint starts from the event called - Sprint Planning. During this meeting, Scrum Team: Developers, Product Owner and Scrum Master collaboratively creates a plan of the work for the upcoming iteration.

The meeting is time-boxed (the same as all events in Scrum) to a maximum of 8 hours for a monthly Sprint. Of course in case of shorter Sprints, the time is adjusted.

To help you understand the Sprint Planning, I would like to continue my analogy to sport from the previous post. This event is like the moment of the start in sprinting (short distance running). If you start running too fast, before the signal to begin, the whole race must be restarted due to false start. On the other hand, if you miss the start, it can jeopardize your whole run and final result.

It is exactly the same in Scrum. The Scrum Team needs to work together to start the Sprint. If someone will start before others, transparency will be lost and it will have a huge impact on the Sprint. Additionally, any delays in start, misunderstandings and not clear requirements can also delay the Sprint and negatively affect the final outcome.

Why?

The first part of the Sprint Planning should be focused on the explanation of "Why?" by the Product Owner. In the Scrum Guide it is explained shortly:

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

I would add to this description an explanation of the high level idea for the product:

• How will the upcoming Sprint impact the development of the product?
• What were the changes from the previous Sprint that impacted the top of the Product Backlog? What needs to be taken into consideration during the Sprint Planning?

From my experience, it is much easier to start working on something if you know the background and understand the purpose of your actions. Of course details for each part of work should be explained in the work item’s Acceptance Criteria, but it is important for the Scrum Team to understand the whole picture.

It can be helpful if the Product Owner starts from the Sprints Roadmap, and explain the Product Goal. I like the roadmap analogy, because I imagine that as a Scrum Team we are starting the trip together. It is much easier to achieve the first goal if we know roughly about the next destinations. FYI - it’s different from the roadmap used in project management. This is just high level vision based on the velocity of the team and it is adjusted whenever changes occur.

The next step of the Sprint Planning is setting up the Sprint Goal by the Scrum Team. It is the objective that they want to achieve during the upcoming iteration. Sprint Goal should be valuable and clear to everyone. It helps the team focus and understand why they are doing their work.

What?

After “Why” of the Sprint it is time for a discussion about what will be done during the Sprint. Product Owner & Developers collaborate on what Product Backlog items will be included in the current Sprint. The list of items selected for the Sprint is called Sprint Backlog.

If it is not the first Sprint of this team, there are some inputs to the Sprint Planning session like:

• Projected capacity - total number of hours that the team will be available during the Sprint.
• Velocity - average amount of Product Backlog turned into Increment during previous Sprints.
• Their Definition of Done - how they will recognize that the work item is “Done”.

It is up to the Developers to select how many work items can be done within the Sprints. It is one the first moments in Scrum when Product Owner needs to trust the team members that they will select the right amount of work based on their expertise and previous experience. Nobody knows better how much work Developers can do during the Sprint than themselves.

How?

Once the Developers knows why they need to do the work during the Sprint and they decide what will be done, it is time to decide how it will happen.

Let’s check what we can read in the Scrum Guide about it:

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

It is not mentioned there, because it seems to be obvious, but Developers need to decide how they will be checking daily if they are going in the right direction with their work. How do they plan to track the work, communicate with each other? They will be meeting on a Daily Scrum, but what more?

There are some technical aspects that I believe need to be discussed:

• How will they track the progress of our work? Do they want to use the Kanban Board? If yes, will they use columns "To do", "In progress" and "Done" or others that will be more accurate for their work?
• Would they like to use tools like Sprint Burndown or Burnup charts to see if they are still on the right track in order to achieve the Sprint Goal?
• How about bugs? Do they consider having items called "bugs"? If yes, how do they plan to manage them?
• What about communication within the team? Do they plan to communicate only face to face or using emails, Microsoft Teams, Zoom or any other tool?

It is possible that there will be more technical aspects that the Scrum Team should discuss. I think that it is important to talk about them and have a common understanding of communication and the whole collaboration process. It doesn’t need to be a long discussion. It can be just a quick agreement to make sure everyone is on the same page.

Once it’s all sorted out, Developers can decide about the size of the items selected to the Sprint. Based on my experience this can also be an element of the regular Backlog Refinement process. There are multiple ways of estimation eg. Planning Poker (by using Fibonacci sequence), T-shirt sizes, Dog sizes etc.

The main purpose of this activity is to have a discussion about items & to use the sum of estimates to calculate the Velocity. It is a great tool that can be used during the planning of the next Sprint.

When all the work is discussed, understood and planned, Developers can start their work. If they discover that they didn’t select enough items for the Sprint Backlog or they selected too many, it can be re-negotiated with the Product Owner.

Summary

The most important takeaways from this post are:

• Scrum Team Developers , Product Owner and Scrum Master) should attend the Sprint Planning meeting.
• Sprint Planning is time-boxed to 8 hours per monthly Sprint.
• The Product Owner should explain “The Why” of the Sprint - what is the value. Based on it, the whole Scrum Team crafts the Sprint Goal.
• PO and Developers discuss items selected for the Sprint, but the final decision about it should be done by Developers.
• The inputs to the Sprint Planning can be: projected capacity, velocity and their Definition of Done.
• Sprint Goal & Sprint Backlog should be the outcome of the Sprint Planning.
• It is important for Developers to discuss how they will be working during the Sprint - all technical aspects: tools, boards, communication etc.
• Developers can estimate during the meeting (or during Backlog Refinement) how much effort is required to complete Product Backlog Items selected for the Sprint.