Practice: Iteration Planning Meeting

Iteration planning determines the work that the team commits to complete in the iteration. When planning, the team’s velocity is taken into account to only accept the amount of user stories that are feasible for the team to take on.

The iteration planning meeting is usually facilitated by the team lead.

Why to Do This Practice

The length of an iteration creates a common cadence and creates boundaries for work. With a fixed iteration length, the product owner and the team adjust scope to fit what can be done in the iteration.

At the beginning of a project, there may be an initial allocation of features or stories to increments based on value or dependencies. However, as the project unfolds, these are revisited frequently, and especially 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 current stakeholder priorities.

Who Does This Practice

Here are the roles involved in this practice:

Team lead, who is the facilitator of the meeting
Product owner, who is the primary sponsor of the meeting, and represents the stakeholders
Full agile team
Stakeholders as necessary (such as product manager, business owners, subject matter experts)

What to Do

Inputs

Inputs to iteration planning include:

Backlog 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 lead has prepared to facilitate the meeting

Approach

Review and understand iteration goals.

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.).
Review stories already planned for the iteration, Discuss, size, split as needed, and ensure stakeholder-clarified acceptance criteria.
Remove or add stories within velocity constraints.
Elaborate any new stories.
Identify and account for any dependencies with other teams.
Ensure selected stories are within highest feature/MBI priority.
Rank stories in priority order (rules for prioritization may vary depending on status of project or environmental changes).
Create and estimate tasks within each story.
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 with the team and the product owner.

Adding, Revising, and Removing Requirements

As customers gain experience with the product, they learn more about what they need. They may develop new requirements, may decide they no longer need something they had asked for earlier, or may change priorities based new findings and situation.

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 modify the product backlog to reflect the customer’s situation:

Add new requirements
Revise existing requirements
Remove existing requirements
Change priorities

After these adjustments are made, the 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 as early as possible in the iteration.
Team composition. If the team composition changes, then they cannot know what their capacity (velocity) will be for the upcoming iterations. 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 usually performs 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.

Outcomes

Iteration planning results in a clear scope of work for the next iteration, feasible for the team to take on.