Iteration Planning

Next, the developers and customers choose an iteration size: typically, 1 or 2 weeks. Once again, the customers choose the stories that they want implemented in the first iteration but cannot choose more stories than will fit according to the current velocity.

The order of the stories within the iteration is a technical decision. The developers implement the stories in the order that makes the most technical sense. The developers may work on the stories serially, finishing each one after the next, or may divvy up the stories and work on them all concurrently. It's entirely up to the developers.

The customers cannot change the stories in the iteration once it has begun. Customers are free to change or reorder any other story in the project but not the ones that the developers are currently working on.

The iteration ends on the specified date, even if all the stories aren't done. The estimates for all the completed stories are totaled, and the velocity for that iteration is calculated. This measure of velocity is then used to plan the next iteration. The rule is very simple: The planned velocity for each iteration is the measured velocity of the previous iteration. If the team got 31 story points done last iteration, it should plan to get 31 story points done in the next. The team's velocity is 31 points per iteration.

This feedback of velocity helps to keep the planning in sync with the team. If the team gains in expertise and skill, the velocity will rise commensurately. If someone is lost from the team, the velocity will fall. If an architecture evolves that facilitates development, the velocity will rise.