Sprint Planning
Sprint Planning
What 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
The Product Owner describes the highest ordered product
backlog item(s)
The team determines and prioritizes what is necessary to
complete that product backlog item(s)
Team members volunteer to own the work
Work owners estimate the ideal hours they need to finish
their work
Planning continues while the team does not exceed determined
capacity
Comments
Post a Comment