Iteration Planning

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.

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 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

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.

Planning Process

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 refinement 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.

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.

Task Capacity

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

Planning Steps

• 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.