Free Agile Playbook

Sprint Planning

What is Sprint Planning?

In Scrum, Sprint Planning initiates the Sprint by having the team collaborate with the Product Owner to agree on outcomes for the upcoming Sprint. The Sprint officially starts at the end of Sprint Planning.

The Product Owner determines the priority of Product Backlog Items (PBIs) and the Delivery Team determines capacity, how much work can be completed and the order in how items will be completed.

What’s the Benefit?

 Sprint Planning is used to determine the following:

  1. What Stories and Backlog Items will be delivered in the upcoming Sprint?
  2. How will the items be completed?


Often 1-2 hours for each week of Sprint length and performed after the previous Sprint has ended and before the start of the upcoming Sprint.

Who attends?

  • Scrum Master (Facilitator)
  • Product Owner
  • Delivery Team (Decision Maker)
  • Subject Matter Experts as needed


  • Backlog of refined Stories meeting the Definition of Ready (DoR)
  • Recent Retrospective Items
  • Upcoming Team schedules


  • A Sprint Plan or Commitment agreed on by the team and Product Owner

Preparing for Success

Team Preparation

The team should prepare upcoming schedules including time-off for holidays, personal leave and other assignments that may impact Sprint Commitments. The team should also be familiar with the highest priority items meeting the Definition of Ready.

Product Owner (PO)

While all candidate Stories for the Sprint should be refined and meet the Definition of Ready before Sprint Planning, the Product Owner should be prepared to answer additional questions including, Who, What, Why and How the Stories align with the Product Roadmap.

Facilitator Preparation

The facilitator should bring Team Velocity (if using), Improvement Backlog Items from the Retrospective and any materials needed for in-person meeting such as stickies and pens.


Sprint Planning is often done in two separate stages although some teams combine these.

Scope or the “What”

The team, along with the Product Owner, selects prioritized items from the backlog which they believe can be completed during the Sprint.

  1. Scrum Master reviews ground rules, if any.
  2. Team calculates capacity by comparing current velocity with the Team’s schedule for the Sprint and may create what is known as “Ideal Days” for completing work.
  3. Product Owner (PO) reviews the Product Roadmap, Upcoming Features and why the prioritized Stories are important.
  4. PO presents the top priority Stories from the Backlog.
  5. The team can discuss adjustments and may recommend “Enabler” Stories.
  6. Team accepts Stories and fills Sprint capacity thinking about “Potentially shippable functionality”.
  7. The team may create a “Sprint Goal statement”.
  8. PO approves Goal and adjusts the backlog as needed.
  9. Team prepares for planning the “How” and may take a short break.

Planning How

  1. PO should continue to be available but may step away.
  2. Team discusses how the work will be delivered and may create tasks for the Stories.
  3. If the team realizes the Sprint Commitment may be at high-risk, the team should contact the PO immediately.
  4. Facilitator reviews action items with Team

Best Practices for Sprint Planning

  • When tasks are being created, multiple team members should be involved with each Story to eliminate gaps, create agreement and cross-pollinate knowledge.
  • The Product Owner decides the priority of the Stories. The team decides on how much can be done.
  • Once items have been entered into the Sprint Commitment, the Team decides the priority of the Stories based on lowering risk.
  • Many Teams use Story Point based Velocity and Capacity to determine how much work can be completed during a Sprint. When Teams have more experience working together, they may bypass points and just come to agreement based on past experience.
  • All Stories accepted into Sprint Planning should meet the Definition of Ready (DoR) through previous Story Refinement sessions.
  • While the Product Owner owns the Team Backlog, the team should leaver some capacity for Technical Debt and Enabler Stories to ensure a sound foundation for the product.
  • While Agile Teams should strive to be cross-functional, often Team members have specialized skills and this should be taken into account when making the Sprint Commitment.