How to Plan an Iteration?

There are many approaches, but the following is relatively typical:

1.

Step one is to decide the length of the iteration; 26 weeks is the common range. In general, shorter is better. Factors that lengthen an iteration include early work with high degrees of discovery and change, large teams, and distributed teams. Recall that once the end date is chosen, it must remained fixedthat's the practice of timeboxing. However, the scope of work for the iteration can be reduced to meet the end date.

2.

Step two is to convene an iteration planning meeting. This is usually done at the end of the current iteration, such as on the final Friday, before work starts on the next iteration on Monday. Ideally at the meeting are present most of the stakeholders: customers (marketing, users, …), developers, chief architect, project manager.

3.	A list of potential goals (new features or use cases, defects, …) for the iteration is presented, ranked by some priority scheme (see p. 130). The goal list usually comes from both the customer (business goals) and the chief architect (technical goals).

4.	Each member of the team is asked for their individual resource budget (in hours or days) for the iteration; for example, people know they will be away on vacation certain days, and so on. All the resource budgets are summed.

5.

For one goal (such as a use case), it is described in some detail, and questions are resolved. Then, the meeting members (especially the developers) are asked to brainstorm the set of more detailed tasks for the goal, with some vague estimates. For example, UI tasks, database tasks, domain layer OO development tasks, external systems integration tasks, and so forth. All the task estimates are summed into a running total.

6.	Step #5 repeats until enough work has been chosen: The iteration task total is divided by the resource budget total. If the work closely fits given the available resources and the timebox deadline date for the iteration, the meeting is finished.