The purpose of the iteration planning meeting is for the team to commit to the completion of a set of the highest-ranked product backlog items. This commitment defines the iteration backlog and is based on the team's velocity or capacity and the length of the iteration timebox.
Who is involved?
Iteration planning is a collaborative effort involving these roles:
- Scrum Master: Facilitates the meeting
- Product Owner: Represents the detail of the product backlog items and their acceptance criteria
- Delivery team: Define the tasks and effort necessary to fulfill the commitment
Before the planning meeting
Before getting started, ensure:
- The items in the product backlog have been sized by the team and assigned a relative story point value
- The product backlog is stack ranked to reflect the priorities of the Product Owner
- There is a general understanding of the acceptance criteria for these ranked backlog items
Equal opportunity backlog
The product backlog addresses new functionality and fixes to existing functionality. The order in which a product backlog item is scheduled is completely independent of its ancestry.
For the purpose of iteration planning, the important characteristics for a product backlog item are:
- It is small enough to be completed in the iteration
- We can verify it has been implemented correctly
Right-size backlog items
Product backlog items too large to be completed in an iteration need to be split into smaller pieces. The best way to split product backlog items is by value, not by process.
If we can split a product backlog item so that its children deliver value, then our iterations incrementally deliver value. If we split by process, then we impact time-to-market because value is not delivered until all the children are complete.
Compound stories can be easily split through disaggregation. Complex stories present a different challenge. Bill Wake enumerates twenty techniques at: http://xp123.com/xplor/xp0512/index.shtml.
Planning the contents of an iteration has two stages: determining how many user stories can fit into the iteration, then breaking those stories down into tasks and assigning owners.
Sizing refers to the relative scope of a user story, and is usually done in relative points. The team periodically estimates the size of a user story, when it is first created, during backlog grooming sessions, and before the planning meeting. By the time planning begins, the team should know what stories near the top of the backlog can fit into the iteration.
Estimation refers to the breakdown of a user story into tasks. Once small steps necessary to deliver a user story are identified, each task is given an hourly estimate. This figure keeps the team updated on how close a task is to being completed. The team also knows how many task hours each team member has available in the iteration (known as capacity), to prevent individuals from being overburdened.
User story points should not translate into or be compared with total task hours.
Sizing and Estimating (5 min)
User story size
Mature teams use past velocity to determine what product backlog items to commit to during the iteration. Velocity is the average number of user story points a team can complete in an iteration. For example, a new team completed 12, 14, and 8 points in their last three iterations. Review meetings revealed that the team was only able to complete 8 story points in the most recent iteration, due to a technical issue that has since been solved. Based on these factors, the team would estimate they have a velocity of 12 story points, to use in the next iteration.
When creating an iteration in Rally, use the Planned Velocity field to record how many user story points (or other value) the team thinks it can complete. New teams may not know their velocity, or it may not be stable enough to use as a basis for iteration planning. An approach for new teams is to make commitments with a best guess based on past project work. If the team quickly completes all of the scheduled work, more can be pulled in. If the velocity estimate is too low, the team should commit to less work in the following iteration.
The capacity for the team is derived from three simple measures for each team member:
- Number of ideal hours in the work day
- Days in the iteration that the person will be available
- Percentage of time the person will dedicate to this team
For example, let's look at a team of five individuals, all committed to the team full-time. Each has about six ideal hours per day to work on tasks, and no one is taking vacation. For a week-long iteration:
5 team members X 6 ideal hours X 5 working days = 150 hours of task capacity
- The Product Owner describes the highest ranked product backlog item.
- The team determines the tasks necessary to complete each product backlog item.
- Team members volunteer to own the tasks.
- Task owners estimate the ideal hours they need to finish each task.
- Planning steps repeat while the team can commit to delivery without exceeding optimum velocity.
If any individual exceeds their capacity during iteration planning, then the team collaborates to distribute the load.
Welcome meeting participants, review purpose, agenda, and organizing tools.
- Product vision and roadmap
Remind the team of the larger picture.
- Development status, state of our architecture, results of previous iterations
Discuss any new information that may impact the plan.
- Iteration name and theme
Make a collaborative decision on name and theme.
- Velocity in previous iterations
Present the velocity to be used for this iteration.
- Iteration timebox (dates, working days)
Determine the timebox and total working days. Subtract days for holidays or other whole team-impacting events.
- Team capacity (availability)
Each team member calculates their capacity based on personal availability, allocation to this and other projects, productive time for tasks in this iteration each day.
- Issues and concerns
Check in on any currently known issues and concerns and record as appropriate.
- Review and update Definition of Done
Review the Definition of Done and make any appropriate updates based on technology, skill, or team makeup changes since the last iteration.
- Stories or items from the product backlog to consider
Present proposed product backlog items to be considered for the iteration backlog.
- Tasking out
Delivery team determines tasks, signs up for work, and estimates tasks they own. Product Owner answers clarifying questions and elaborates acceptance criteria as appropriate; Scrum Master facilitates collaboration.
a. Tasks, b. Estimates, c. Owners
- New issues and concerns
Check in on any new issues and concerns based on tasking out and record as appropriate.
- Dependencies and assumptions
Check in on any dependencies or assumptions determined during planning and record as appropriate.
Scrum Master calls for a fist of five on the plan. Agile team and Product Owner signal if this is the best plan they can make given what they know right now and commit to moving to the next level of planning—daily.
- Communication and logistics plan
Review and update communication and logistics plan for this iteration.
- Parking lot
Process parking lot—all items should either be determined resolved or turned into action items.
- Action items/plan
Process action plan—distribute action items to owners.
- Retrospect the meeting
Because we want these meetings to be useful for everyone, we solicit feedback on the meeting itself.
Celebrate a successful planning meeting!