Skip to main content

Simple Cheat Sheet to Sprint Planning Meeting

Derek Huether
Reading: Simple Cheat Sheet to Sprint Planning Meeting

What is Sprint Planning?

Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of product backlog items.  This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.

Who does it?

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

How do we prepare?

Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

  • Assign a relative story point value
  • Remove dependencies
  • Create testable examples
  • Define acceptance criteria
  • Meets INVEST criteria

What is the backlog?

The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 

Ensure Right Sizing Backlog Items

Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.

Calculating a Commitment

To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.

Determining Velocity

First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.

Determining Capacity

For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?

The Planning Steps

  1. Remind the team of the big picture or goal
  2. Discuss any new information that may impact the plan
  3. Present the velocity to be used for this release
  4. Confirm team capacity
  5. Confirm any currently known issues and concerns and record as appropriate
  6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
  7. Present proposed product backlog items to consider for the sprint backlog
  8. Determine the needs, sign up for work, and estimate the work owned
  9. Product Owner answers clarifying questions and elaborates acceptance criteria
  10. Confirm any new issues and concerns raised during meeting and record
  11. Confirm any assumptions or dependencies discovered during planning and record
  12. ScrumMaster calls for a group consensus on the plan
  13. Team and Product Owner signal if this is the best plan they can make given what they know right now
  14. Get back to work

Is Your Team New to Scrum? Check Out This Post, Too. 

Next No Excuses

VP of ALM Platforms; Advisor on #Productivity #Metrics & Tools | Improver of things | Author: Zombie Project Management | Speaker | Podcaster | Always drinking #coffee or #running

Comments (8)

  1. Simon
    Reply

    Don’t forget the sprint goal!

    Reply
    • Derek Huether
      Reply

      Simon, I totally agree with you. The team should have a shared understanding of the goal of the sprint. As I noted above, “All items to be discussed reflect the greatest needs as identified by the Product Owner at the time of the meeting.”

      I do believe the Product Owner could paraphrase into a “theme” of the sprint.

      Thanks for the comment!

      Reply

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

What is the Worth of a Good Product Owner? w/ Tim Wise

This week, on SoundNotes, we’re featuring another question from a student in one of our Certified Scrum classes. The question came from someone who’s working in an organization that doesn’t see value in the role of Product Owner and isn’t convinced that it’s needed as part of the Scrum Team. The question: What is the […]

How Do I Use Scrum on Data Warehouse Projects? w/ Dave Nicolette

In one of my recent Certified Scrum Master classes, I had a number of students who were working on projects involving migrating from a legacy data warehouse to new data warehouses. Figuring out how to apply Scrum to the work they were doing presented a number of challenges and left some open questions.  Here are […]

Maximizing the Amount of Work Not Done

One of the principles of the Agile Manifesto reads: “Simplicity – the art of maximizing the amount of work not done – is essential.” Okay. What does that mean? Does it mean we should avoid doing our work to the extent possible? Well, not exactly. Consistency Between Lean and Agile Principles Without coming at the […]

Prioritizing the Work to Maximize Return w/ Dennis Stevens

This week, on SoundNotes, we’ve got Part 3 of a trio of interviews with LeadingAgile Chief Methodologist and Co-Founder Dennis Stevens. The series focuses on how to build an organization that can embrace change. In the final episode of the series, Dennis and Dave cover how to prioritize work being done to maximize return. During […]