Agile Glossary

Sprint Planning

What is Sprint Planning?

Sprint planning is an event in the Scrum framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items.

Teams may find it helpful to establish a sprint goal and use that as the basis by which they determine which product backlog items they work on during that sprint.

Who is involved in Sprint Planning

Sprint planning typically involves the entire team.

product owner identifies the candidate product backlog items and their relative priorities, as well as proposes a sprint goal.

The team members determine how many of the product backlog items they forecast they will be able to complete and determine how they will deliver those product backlog items.

scrum master or coach typically facilitates sprint planning in order to ensure that the discussion is effective and that there is an agreement on the sprint goal and that the appropriate product backlog items are included in the sprint backlog.

Where does Sprint Planning take place?

A good location for sprint planning is the team room so that you have access to all the information about your product backlog and you can reference and update any information radiators you may use.

If your team is distributed, sprint planning represents a good opportunity to gather everyone together so that your planning discussions can be more effective and reinforce the person-to-person connections of the team.

When does Sprint Planning take place?

Sprint planning occurs on the first day of a new sprint.

The event should occur after the sprint review and retrospective from the previous sprint so that any output from those discussions can be considered when planning for the new sprint. It does not have to occur immediately after those other two events. You’ll find it’s best to place a higher priority on scheduling sprint planning when the entire team is available.

You may find that it’s best to have a standing consistent time for sprint planning so that your team can keep that time slot clear from other engagements.

How is Sprint Planning Structured?

Sprint planning is typically split into two parts:

Part 1 – Scope

The team selects which items from a prioritized list of ready product backlog items (usually expressed as user stories) they forecast they will be able to complete during the sprint.

Here’s a sample agenda for the first part of sprint planning:

  • What is the goal for this sprint? Use this as a decision filter to determine which product backlog items to include in the sprint.
  • What product backlog items are ready and contribute toward the sprint goal?
  • Who is available for this sprint? Identify any vacations, holidays, or other activities that will impact everyone’s availability during the sprint.
  • What is the team’s capacity based on everyone’s availability
  • What items will the team include on the sprint backlog based on the sprint goal and the team’s capacity?
  • How confident does the team feel that they’ll be able to meet the sprint goal?

Part 2 – Plan

The team discusses in more detail how they will deliver the selected product backlog items. This may (but does not have to) include identifying tasks for the product backlog items, whether there are any dependencies between the items, and signing up for the initial product backlog items that each team member works on.


Also Known As

In cases where teams try to avoid Scrum-specific language, this event may be called iteration planning.


Expected Benefits

The main benefit of sprint planning is that it allows a team to start a new sprint with a shared understanding of what they will work on for that sprint, as well as an initial plan for how they approach that work.


Common Pitfalls

Sprint planning can become ineffective when your team does not have a properly refined product backlog from which to draw product backlog items. If you find yourself in this situation you inevitably have to spend time during sprint planning developing a better understanding of the product backlog items, which may include splitting stories and estimating.

You can address this issue by establishing a consistent backlog refinement process that results in a set of product backlog items that meet an agreed definition of ready. Those ready product backlog items can then serve as the potential product backlog items you consider for inclusion in the sprint.

Another issue arises when you don’t establish a specific goal for the sprint and wind up with a set of unrelated items that the team has to work on. This can result in your team performing a sprint’s worth of work but not feeling as though they’ve made a lot of progress.


When Applicable

Sprint planning is typically used when your team is following the Sprint framework, or the team’s methodology involved timeboxed iterations.

If you’re following a flow-based approach, you may still find an event similar to sprint planning helpful to build a shared understanding of the items that are queued up to work on next.


Potential Costs

Sprint planning can become costly when your team spends an inordinate amount of time planning compared to the act of delivering the product backlog items.

The Scrum Guide identifies a maximum of 8 hours for a month-long sprint. Many teams that follow a two-week sprint are able to effectively complete both parts of sprint planning within 1 – 2 hours.


Origins

Sprint Planning is one of the original Scrum events and was created as part of that framework.


Further Reading

Scrum Guide entry on Sprint Planning

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Privacy Preference Center

Not yet a member? Sign up now