Iteration Planning

The development of an iteration plan has four steps:

1. Determine the iteration scope. Determine the intentwhat you want to accomplish in the iteration.

2. Define iteration evaluation criteria. Define how to objectively evaluate the accomplishments at the end of the iteration; specify which artifacts will be worked on.

3. Define iteration activities. Establish what needs to be done and on which artifacts.

4. Assign responsibilities. Allocate resources to execute the activities.

How to proceed with the first three steps will vary greatly across the lifecycle.

Inception and Elaboration

At the beginning of a project, especially a green-field project, you have no design elements identified and no elements specific to this new system on which to base your reasoning for planning the iteration. Use a top-down approach, with rough estimates derived from other projects, as a basis for your planning assumptionsyou probably did this for the project plan.

If, however, you are dealing with an evolution cycle of an existing software product (a "brown-field" project), Inception and Elaboration are likely to be shorter, you may have fewer risks to mitigate, and planning iterations will look more like what is described in the next section, Construction and Transition.

The objectives of the iteration will be determined primarily by risks. Risks will in turn determine which use cases, scenarios, algorithms, and so on will be developed during the iteration, together with the means to assess that the risks have been mitigated.

Construction and Transition

Now you have an overall architecture in place and some measurements from previous iterations both on the artifacts (lines of code, defects, and so on) and on the process (time to complete certain tasks ). Hopefully, you have mitigated most of your risks. You can use this information to progressively modify the way you plan iterations.

You can proceed with a bottom-up, artifact-based planning, using the elements of the design, such as class, component, subsystem, use case, test case, and so on, as well as any measures from previous iterations to estimate the effort. A word of warning: A bottom-up approach tends to be pessimistic relative to the schedule, especially when summing up the individual estimates of dozens of people. And it is known that novice developers have a tendency to be overly optimistic about their performance.

The iteration objectives will be determined primarily by completion objectives and the achievement of a set level of quality. This also includes specific defects to correct, primarily the ones that prevent the use of major functionality, or make the system crash, deferring "nice to haves" for a future release.

Identifying Activities

Use your RUP development case as the reference list for activities required within an iteration. If you find the activities are too granular, you may replace them by workflow details, especially in the early stages.

There are some activities that need to be run only once per iteration (or per phase or even per cycle); for example, the RUP activities named Plan an Iteration or Lifecycle Milestone Review.

But there are other activities that must be instantiated (replicated) for each element, and this element is usually the major output of this activity. For example, the activity Code a Class must be done for each class, Integrate Subsystem for each subsystem, and Describe Use Case for each use case.

Consequently, in the very early iterations of a new project, since the design elements have not been identified, you will only be able to give that activity a sort of global "ballpark" figure, for example:

Code (all) classes: 10 person-days

Or simply picking a higher-level artifact:

Develop proof-of-concept prototype: 42 person-days

In later iterations, when the design elements are identified, the activity can be associated with these elements with a finer estimate; for example:

Code Customer class: 2 person-days

Code Invoice class: 1 person-day