Iteration planning determines the work that the team commits to be completed in the iteration by adjusting the predicted velocity and managing the number and priority of assigned, deferred, and/or new stories. The Iteration Planning Meeting is usually facilitated by the Team Agility Coach.

Why to do this practice

The length of an iteration enforces a common cadence and creates boundaries for work. With a fixed iteration length, the Product Owner and the team adjusts scope and cost to fit what can be done in the iteration.

At the beginning of a project, there may be an initial allocations of features or stories to increments based on value or dependencies. However, as the project unfolds, these are revisited at the beginning of each iteration to ensure that the scope of the iteration is reasonable given the current team capacity and that it includes high value work based on the changing environment at the stakeholder and business value level.

Who does this practice

Here are the roles involved in this practice:

• Team Agility Coach, who is the facilitator of the demonstration
• Product Owner, who is the primary sponsor of the meeting
• Full Agile Team
• Stakeholders as necessary (such as Product Manager, Business Owners, Subject Matter Experts)

What to do

Inputs

Inputs to iteration planning include:

• Back log of user stories, preferably elaborated (refined, sized, and with initial-acceptance criteria)
• Carry over stories from previous iteration
• Team velocity over past increments
• The Team Agility Coach has prepared to facilitate the meeting
• Completed Iteration 0

Approach

1. Review and understand iteration goals.
2. Review current velocity and adjust as needed (take into account holidays, time off, corporate events, team member availability, and change in complexity of or experience with stories, etc.).
3. Review stories already planned for the iteration, Discuss, size, split as needed, and ensure stakeholder-clarified acceptance criteria.
4. Remove or add stories within velocity constraints.
5. Elaborate any new stories as before.
6. Identify and account for any dependencies with other teams (may require interactions with other teams or the system architect.
7. Ensure selected stories are within highest Feature/MBI priority.
8. Rank stories in priority order (rules for prioritization may vary depending on status of project or environmental changes).
9. Create and estimate tasks within each story.
10. Identify lessons from previous iterations that the team wants to incorporate into this iteration.

Discussion

Here are variances to iteration planning:

• Tasks and estimations may happen in a follow up session.
• Individuals may task and estimate.

Iteration planning should be done as a collaborative exercise. Collaboration establishes a reasonable set of stories to implement within the increment given current team, project and stakeholder status.

Adding, revising, and removing requirements

As customers gain experience with the product, they learn more about what they need. They may development new requirements, may decide they no longer need something they had asked for, or may decide that something is more important or less important than before.

At the end of each iteration, based on what the customer has learned from seeing and using the product, the Product Manager (acting as advocate for the customer) can:

• Add new requirements
• Revise existing requirements
• Remove existing requirements

After these adjustments are made, the collection of requirements are then prioritized and used as input for the next iteration.

Issues and considerations

Here are some issues to consider.

• Lack of a known velocity. When the team’s velocity is not known, populate the backlog using size rather than velocity.
• Testing was not done. If testing has not been finished by the end of the iteration, then the team cannot know how much testing resource is available in the next iteration. Move testing early in the iteration.
• Team composition. If the team composition changes, then they cannot know what their capacity (velocity) will be for the upcoming. Treat their velocity estimate as a guess, just like it was at the first iteration.
• Frequent interruptions. Establish a process to handle interruptions from management, other projects, etc. so that teams are not blind-sided by interruptions in the middle of an iteration. Perhaps schedule time at the end of the iteration for other work. If interruptions become too frequent, institute a single point of contact (an interruption bottleneck or a “bouncer”) to limit the impact. The Team Lead or Team Agility Coach can perform this function for the team.
• People are not available. If all team members are not available to plan together, the plan will almost certainly be incomplete, inadequate, and erroneous. Adjusting during execution is wasted effort.

Outputs

Iteration planning results in an iteration backlog. It is populated with stories and any subtasks that are sized, ranked, have agreed to acceptance criteria; project board and team environment set up and cleaned up; team is committed to next iteration.

When to do this practice

Iteration planning is done on the first day of every iteration.

Where to do this practice

Iteration planning is done in a meeting room near the team or people who are involved in the iteration.

Outcomes

Iteration planning results in a clear scope of work for the next iteration must be feasible for the current team.