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.

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

Plan based on capacity

Mature teams may use velocity to determine what product backlog items to commit to during the iteration.

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 based on the team's capacity.

Determine 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

Planning steps

1. The Product Owner describes the highest ranked product backlog item.
2. The team determines the tasks necessary to complete that product backlog item.
3. Team members volunteer to own the tasks.
4. Task owners estimate the ideal hours they need to finish their task.
5. Planning continues while the team can commit to delivery without exceeding capacity.

If any individual exceeds their capacity during iteration planning, then the team collaborates to better distribute the load.

Agenda

1. Opening
   Welcome meeting participants, review purpose, agenda, and organizing tools.
2. Product vision and roadmap
   Remind the team of the larger picture.
3. Development status, state of our architecture, results of previous iterations
   Discuss any new information that may impact the plan.
4. Iteration name and theme
   Make a collaborative decision on name and theme.
5. Velocity in previous iterations
   Present the velocity to be used for this release.
6. Iteration timebox (dates, working days)
   Determine the timebox and total working days. Subtract days for holidays or other whole team-impacting events.
7. 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.
8. Issues and concerns
   Check in on any currently known issues and concerns and record as appropriate.
9. 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.
10. Stories or items from the product backlog to consider
    Present proposed product backlog items to be considered for the iteration backlog.
11. 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
12. New issues and concerns
    Check in on any new issues and concerns based on tasking out and record as appropriate.
13. Dependencies and assumptions
    Check in on any dependencies or assumptions determined during planning and record as appropriate.
14. Commit!
    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.
15. Communication and logistics plan
    Review and update communication and logistics plan for this iteration.
16. Parking lot
    Process parking lot—all items should either be determined resolved or turned into action items.
17. Action items/plan
    Process action plan—distribute action items to owners.
18. Retrospect the meeting
    Because we want these meetings to be useful for everyone, we solicit feedback on the meeting itself.
19. Close
    Celebrate a successful planning meeting!