Simple Cheat Sheet to Sprint Planning Meeting

WRITTEN BY Derek Huether

Scrum ImagesWhat is it?

In textbook Scrum, the purpose of the Sprint Planning Meeting is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

Who does it?

Sprint planning is a collaborative effort involving:

  • ScrumMaster – to facilitate the meeting
  • Product Owner – to clarify the details of the product backlog items and their respective acceptance criteria
  • Entire Agile Team –to define the work and effort necessary to meet their commitment to complete product backlog items

Before You Begin

Ensure all items to be discussed meet the teams definition of “ready”, to include (for example):

  • relative story point value
  • dependencies removed
  • testable examples
  • clearly defined acceptance criteria

All items to be discussed reflect the greatest needs as identified by the Product Owner at the time of the meeting.  There needs to be a general understanding (and agreement) of the acceptance criteria for these top-ordered backlog items.

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Plan Based on Capacity

Mature teams may use a combination of team availability and velocity to forecast what product backlog items can be finished during the sprint.  New teams may not know their velocity or it may not be stable enough to use as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the team’s capacity.

Determining Velocity

The velocity of a team is derived by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.  Never use the velocity of another team to plan your sprint.

Determining Capacity

For teams without a stable velocity, the capacity of a team could be derived from three simple measures for each team member:

  • Number of ideal hours in the work day
  • Days in the sprint that the person will be available
  • Percentage of time the person will dedicate to this team

The Planning Steps

  1. The Product Owner describes the highest ordered product backlog item(s)
  2. The team determines and prioritizes what is necessary to complete that product backlog item(s)
  3. Team members volunteer to own the work
  4. Work owners estimate the ideal hours they need to finish their work
  5. Planning continues while the team does not exceed determined capacity
Image Source: Pictofigo Premium

 

leave a comment

Leave a comment

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

6 comments on “Simple Cheat Sheet to Sprint Planning Meeting”

  1. Your Team Is New To Scrum | LeadingAgile

    […] while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new […]

    Reply
  2. Your Team Is New To Scrum | All About Agile

    […] while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new […]

    Reply
  3. Simon

    Don’t forget the sprint goal!

    Reply
    • Derek Huether

      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