Sprint Planning Meeting

Reviewed by: Bernie Maloney, Madhur Kathuria, and Raúl Herranz

In the sprint planning meeting, the scrum team collaborates to plan the work for the current sprint. Sprint planning is one of the five events of the scrum framework. The purpose of the event is to discuss why the sprint is valuable (i.e., the goal of the sprint), what product backlog items can be completed during the sprint, and how the work will get done.

What Is Sprint Planning?

Sprint planning is the event that enables the scrum team to lay out the work they will do in the current sprint. The meeting isn’t about an upcoming sprint or the next sprint; Instead, it kicks off the current sprint.

A Fundamental Event

The Scrum Guide describes five events in the scrum framework:

• The sprint (it contains the other four events and all activities)
• Sprint planning
• Daily scrum
• Sprint review
• Sprint retrospective

Like all of the events, sprint planning is an opportunity to inspect and adapt. In sprint planning, the team may inspect product backlog items, the product goal, recent increments, and sprint review feedback as part of planning what they’ll focus on next. They may adapt the product backlog and their sprint plan based on their inspection.

Who Goes to Sprint Planning?

The scrum team attends – product owner, scrum master, and developers (the term “developers” means anyone who is creating work deliverables; it’s not confined to people who write code). Each scrum team member has value to add to this event:

• The product owner talks to the team about the highest priority items in the ordered product backlog. They offer insight into how the most value can be provided in the sprint and help the team create a sprint goal. Or, it’s also possible that the product owner will propose a sprint goal and a set of product backlog items (PBIs) that will help the scrum team achieve this goal through the sprint. 
• The developers may decide which product backlog items to pull into the sprint and how the work will be accomplished. They may examine the goal and PBIs proposed by the PO and discuss the ways to accomplish them, negotiating the PBIs or the sprint goal with the PO if necessary.
• The scrum master may provide guidance, coaching, and support as needed, which will vary. For example, a scrum master may facilitate work negotiation between the developers and the product owner. 

Your team’s sprint planning agenda may look a little different. The ultimate goal, regardless of how you structure the event, is to decide what can be delivered in the sprint and how it will be delivered.

The scrum team may invite other people to sprint planning if they need input, advice, or collaboration. But the scrum team members are the essential attendees.

Timeboxing the Event

The Scrum Guide explains that a one-month sprint should have a sprint planning timebox not exceeding eight hours. Remember that these timeboxes are maximums, not minimums or exact durations. The timebox is a constraint that encourages focus on the highest priority items.

For shorter sprints – one or two-week sprints, for example – the timebox is usually shorter. Teams working in one-week sprints often timebox planning to one or two hours.

What Happens in the Sprint Planning Meeting

The Scrum Guide describes three topic areas to focus on in sprint planning:

• The why: developing a sprint goal 
• The what: what work can be done in the sprint
• The how: how the work will be accomplished

Establishing the Sprint Goal: The "Why" of Sprint Planning

First, the team determines why this sprint is valuable. Looking at the ordered product backlog, how can the team provide value to stakeholders? What does the product owner know about how the value of the product can be increased, and which items in the backlog will make progress toward that increased value?

Determine the sprint goal: A sprint goal is one outcome of sprint planning. In a sentence or two, it communicates the value the team is providing this sprint and can easily be shared with stakeholders or people outside the team for transparency. It provides the scrum team with an objective, which can also be used to negotiate work to achieve that objective if conditions change during the sprint. And the sprint goal creates coherence and focus for the team to work together.

• Example: Create a dashboard that allows new hires to complete all the onboarding paperwork in one step.
• Example: Enable website users to use a digital wallet at checkout.

Ideally, the work performed in the sprint will achieve the goal.

What Work Can be Done in the Sprint

Next, the developers and the product owner review the product backlog items. The items should be ordered by priority so that everyone knows where to focus first. If the team has been refining these items throughout previous sprints, there should be detail about each item.

They determine what subset of the product backlog can and should be worked on in this sprint to achieve the sprint goal and produce an increment of value that meets their definition of done. The team pulls PBIs into the sprint backlog.

Selecting how much work they can accomplish in the sprint is not a perfect science. The developers may consider:

• Their past performance
• Scheduled time off
• Holidays occurring during the sprint
• Whether all the required skillsets to complete the work are present in the team

Once the developers add PBIs to the sprint backlog, they have forecasted that they’ll be able to complete those items during the sprint.

How the Work Will be Accomplished

As the sprint backlog is getting populated with product backlog items to work on, the developers discuss how the work of each item will be completed.

Only the developers can make these decisions. The “how” of the work should not be dictated by anyone else, but the developers may ask for advice or information to help them make tactical decisions.

The developers discuss the steps required to complete each product backlog item. This is their detailed plan of what they must do. The team may have come up with many of these details already in previous refinement activities. The developers will often break down the product backlog items into smaller chunks of work to be completed in the sprint. 

At this point, scrum teams may decide who will collaborate on the specific work items, and they may estimate the work with t-shirt sizes (Is the work small? Medium? Large, or x-large?), dot voting (the whole team votes in dots on the effort of the work), in story points, or using another system of effort estimation.

With a sprint backlog, goal, and plan in place, the team is ready to take on the sprint!

Learn More About Scrum

Whether you’re new to using the scrum framework or you’re experienced and looking to grow your knowledge, the Scrum Alliance Resource Library features informative articles for every agilist. Please subscribe to our emails to get new articles delivered straight to your inbox.