We know that product development comprises of several Sprints. Each Sprint delivers a working increment of the product. So how do we decide what goes in a Sprint? Sprint Planning does this. Every Sprint begins with Sprint planning when the entire Scrum team gets together to agree on what needs to deliver in the Sprint (Sprint Goals). It is one of the essential Scrum events, and getting this right is crucial for necessary for the success of Sprint. Let's discuss this in detail

• What is Sprint Planning?
  • Timing for Sprint Planning
  • Who attends the Sprint Planning Meeting?
  • Where does the Sprint planning meeting take place?
• How do we do Sprint Planning?
• Common Sprint Planning Questions

What is Sprint Planning?

Sprint planning is an event in Scrum that kicks off the Sprint. It's the first event that happens during a Sprint. The main agenda of Sprint planning is to define the scope of delivery and how to accomplish that work. It sets up a common goal for the team, and everyone's focus is to achieve that goal during the Sprint.

Before we go any further, let's review some terminology that we will be using in this article. I would recommend that you read our articles on Product Backlog and Sprint for more details.

• Product Backlog -  It's a single source of requirements for everything needed in the product. It includes new features, changes to existing features, bug fixes, infrastructure setups, etc.
• Story -  It records the description of a software feature from an end-user perspective. E.g., As a customer, I want to register on the website, so that I can browse the products on the site.

Note that Scrum doesn't say that the requirements need to be in the story format. As per Scrum, you can have the requirements in any form, though the story is the most popular format to document requirements.

Timing for Sprint Planning

We timebox the Sprint Planning to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually quicker. As a thumb rule, we can multiply the number of weeks in your Sprint by two hours to get your total Sprint planning meeting length. Note that this is the maximum time allotted, and usually, the experienced Scrum teams will take lesser than this time.

• 1 Week Sprint = 2 Hours
• 2 Week Sprint = 4 Hours
• 3 Week Sprint = 6 Hours
• 4 Week Sprint = 8 Hours

Parkinson's law states that work expands to the time allotted. The Scrum Master ensures that the meeting does not take more than this time, and any conversation that is not needed is parked.

Who Attends the Sprint Planning Meeting?

• Product Owner(PO)- The PO will prioritize the backlog items, and propose the Sprint goal. In addition to this, the PO will also provide any clarifications that the team may have during the planning.*
• Development Team - They will determine how many backlog items they can complete and how they will do it.
• Scrum Master(SM)- The SM will facilitate the Sprint planning meeting and ensure that discussion is productive, and there is an agreement on the Sprint goal and product backlog items that the Sprint scope includes.*

Where does the Sprint planning meeting take place?

Sprint planning meeting usually happens in a team room, where all the team can sit together at one place. If there is a divided team, Sprint planning presents an excellent opportunity to gather everyone together so that the planning discussions can be more productive. It also helps to reinforce the person to person connections of the team

Inputs to Scrum Planning Meeting:

• The Latest Product Increment
• Product Backlog
• The capacity of Team in Sprint
• Past Performance of Development Team

We will discuss each of these in detail further in the article.

How do we do Sprint Planning?

Sprint Planning answers the following:

• What can deliver in the Increment resulting from the Sprint?- The Scope
• How to accomplish the work needed to deliver the Increment? - The Plan

We can split the Sprint Planning meeting into two parts - The Scope and The Plan. Let's understand each one of them in detail.

Define the Scope of Sprint:

The First step of Sprint planning is to finalize the scope for the Sprint. The product owner plays an active role in helping out the development team to finalize the scope. Let's understand the steps involved to finalize this scope:

1) Define Sprint Goal -

Each Sprint needs to have a potentially releasable deliverable. How do we achieve that? By having a clearly defined Sprint goal. Imagine if we pick up half of the login, half of the registration, and few stories of the home page in a Sprint. Theoretically, we are still progressing, and work is getting done, but can we release it? Therefore, we must define the Sprint goal first.

Who defines it? The responsibility to determine the Sprint goal is with the product owner. However, the team is equally involved as well, so that they all are on the same page on the Sprint goal. The basis of the Sprint goal is the essential features of the product that needs to build first. One of the critical inputs in defining the Sprint goal is the latest product, increment. In other words, it means, if a product is already under development, then what functionalities we have already created and what makes the best sense to pick up next.

As an example, if we are building Cart functionality of a website, and in Sprint 1, we could complete only half of it, then it would make more sense to complete the rest of it before taking any other features. Examples of Sprint goal could be - "Create login and registration capabilities for customers so they can utilize email and social login features" Sprint goal should not be vague - E.g., Improve performance of the home page. Instead, we should have a clear goal like Improve the page load time of the home page by 10%.

2) Story Selection -

Now that we know the Sprint goal and the team's alignment with it, the next step is to select the stories that correspond to the Sprint goal. One of the critical inputs to the Sprint planning meeting is - the product backlog. It has all the stories that need work, and the team selects the stories from this backlog. Product Owner helps in prioritizing this list. This, in turn, ensures that the correct alignment of the Story chosen to the Sprint goals. Once we select the stories for the Sprint, they are called Sprint Backlog. The product owner helps in clarifying any doubts that the development team may have on the Story description.

3) Capacity Planning -

The sprint goal is defined, and we have got the Sprint stories from the product backlog. Can we do it all in the Sprint? It depends on Sprint Capacity. In simple terms, the stories taken in the Sprint will require some effort - Say 100 Days. So we need to find out whether we have 100 days worth of effort is available in the team.

Let's assume the team is working on a two weeks Sprint. At the outset, we know that we don't have ten days available. We need to commit some time for Sprint planning, Sprint Review, and Sprint Retrospective meetings. Apart from that, the team might need to reserve some time for supporting production activities or any other work beyond current Sprint goals. We also need to consider that not all 8 hours are available with the team. They would need to attend some organization meetings and participate in account-level activities. Also, we should consider that the team members may plan personal time off.

There are so many dynamics involved daily - Who keeps track of all this? It is the job of the Scrum Master, who has the primary ownership of capacity planning.

There are two approaches to do capacity planning.

• Capacity in Story Points - Scrum team gets together to assign points to a story. It is based on the amount of work to be done, the complexity of work, and accounting for any uncertainties involved in doing the work. Moreover, the story points are abstract and relative. It means that for a login story, your project may have given two story points, while another project has given it 4 story points. Each project team has its logic of defining story points. Additionally, this logic needs to be consistent throughout the Sprint. Also, the story point is relative. E.g., the Login story gets 4 story points.  The ability to add the product to Cart has got double the effort, so it needs 8 story points. Now instead of 4,8, you can give 2,4 story points or 1,2 points.

Scrum doesn't tell which way you should give these points. A prevalent method is planning poker, where the entire team holds up a card with the number that reflects their estimate. Scrum Master will facilitate if the calculation differs, and a standard agreement or average acts as a story point.

Over a while, the Sprint team would find out the average number of story points the team can deliver in a Sprint. It is known as the Past performance of the team, and it's an input to determine the story points' capacity of the team. Each story in the Sprint backlog gets a story point. The comparison of the total number of story points to the average story points the team has been doing takes place. Based on that, the team will work with the product owner to negotiate the scope or to bring an additional scope.

• Capacity in Effort Hours - It's an easy way to do capacity planning. Assume a 2 weeks Sprint with 5 team members. 1 Day will go in Sprint planning, review, and retrospection, so 9 days are left for Sprint. If each of the team members will have productive hours as 6 every day, then the total capacity available is 659 = 270 Hours. The stories selected for Sprint are estimated in hours and compared with available capacity. Based on that, the team will work with the product owner to negotiate the scope or to bring additional scope.

Planning the Scope:

We have now got the Sprint backlog, and its alignment is as per the team's capacity - What next? We need to plan the completion of this work within the Sprint. The development team takes the lead here, and the product owner is present to clarify any doubt that the team may have. The team will take stories defined in the Sprint backlog and break down each story into multiple tasks. The team identifies whether there are any dependencies to complete a task, and they will put hours against each task. Therefore, they will know when all the tasks finish. The Scrum master compares the task estimate with an original estimate to make sure the initial commitment was realistic. It may lead to some further trade-off with the Product Owner.

The output of a Sprint planning meeting is a finalized Sprint goal and Sprint Backlog. By the end of the Sprint planning meeting, the tasks that are required to finish on the first day get assigned to the development team. The Scrum master will keep assigning further tasks to the team daily.

Common Sprint Planning Questions

Let's have a look at some of the common questions that people have on Sprint planning

We have created a perfect plan, but what if someone falls ill? Do we extend the Sprint timeline to cover it?

We don't extend the Sprint time, as it will impact future Sprints. Usually, the Scrum Master always keeps some buffer with them. If Sprint capacity is 100 person-days, they will plan for stories worth 90-95 days. It helps them to cover up if someone falls sick. In rare situations, if someone becomes unavailable for a longer duration, then the Scrum Master will inform the product owner, and re-negotiate some of the pending scopes.

What happens if Scrum Master himself falls ill?

In this case, the expectation is that the senior members of the Scrum team run the daily Scrum meeting. They can use these meetings to assign tasks to the team. In cases where Scrum Master will not be available for a longer duration, the organization usually appoints a temporary Scrum Master or a Scrum Master from another team can do the part backfilling.

Who has the final say on stories to take in Sprint backlog? The Product Owner or Scrum Master?

Contrary to what most people think, the number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. The Product Owner helps in the prioritization of backlog and helps in coming up with the Sprint Goal. The Scrum Master only facilitates these activities. Therefore, the development team needs to follow this prioritization. E.g. The product owner has prioritized Login and Registration functionalities in product Backlog, and he intends to take these in Sprint. The development team cannot choose Home page functionality instead. However, what stories in login/registration they can do in the Sprint is solely decided by the development team.