RUP- building an iteration plan

An Iteration Plan is a fine-grained,time-boxed plan; there is one per
iteration. As each Iteration Plan
focuses on only one iteration, it has a
time span small enough to let the
planners do a good job of detailing
tasks with the right level of granularity and allocating them to appropriate
team members.
A project usually has two Iteration Plans active at any time:
- a plan for the current iteration, to track progress for the iteration
that is underway.
- a plan for the next iteration, which is built toward the second half of
the current iteration and is ready at the end of it.

The development of an Iteration Plan has four steps:

1. Determine the iteration scope (i.e., what you want to accomplish in the iteration)
2. Define iteration evaluation criteria (i.e.,specify which artifacts will be worked on)
3. Define iteration activities (what work needs to be done, and on which artifacts)
4. Assign responsibilities (allocate resources to execute the
activities).

Inception and Elaboration
At the beginning of a project, especially a green-field project, you will not
yet have identified design elements specific to the new system on which to
base your planning the iteration. So instead, use a top-down approach,
with rough estimates derived from other projects as a basis for your
planning assumptions; in fact, you probably did just this for the Project
Plan.
If, however, you are dealing with an evolution cycle for an existing
software product, Inception and
Elaboration are likely to be shorter and you may have fewer risks to mitigate.
The objectives of the iteration will be determined primarily by risks, which
will, in turn, determine which use cases, scenarios, algorithms, and so on,
will be developed during the iteration. The risks will also determine what
means to use in order to assess whether the risks have been mitigated.

Construction and Transition
By the time you have an overall architecture in place, some
measurements from previous iterations relating to artifacts (lines of code,
defects, etc.) and process (time to complete certain tasks), hopefully, you
will also have mitigated most of your risks.
Now, you can proceed with a bottom-up, artifact-based planning
approach, using design elements such as class, component, subsystem,
use case, test case, and so on, as well as any measures from previous
iterations to estimate the effort.
The iteration objectives will be determined primarily by completion
objectives, and achievement of a set level of quality. This also includes
specific defects to correct, primarily those that prevent the use of major
functionality or make the system crash; it also includes deferring "nice to
haves" for future releases.
Identifying Activities
There are some activities that need to be run only once per iteration (or
per phase or even per cycle). Both Plan an Iteration and Lifecycle
Milestone Review fall into this category.
But other activities must be instantiated (replicated) for each element, and
the element is usually the activity's major output. For example: Code a
Class must be done for each class; Integrate Subsystem must be done for
each subsystem and Describe Use Case must be done for each use case.
Consequently, in the very early iterations of a new project, because the
design elements have not been identified, you will only be able to assign a
"ballpark" figure to each activity. For example:
Code (all) classes: 5 person-days
Or, for a higher-level artifact:
Develop proof-of-concept prototype: 20 person-days
In later iterations, when the design elements are identified, activities can
be associated to these elements with finer estimates. For example:
Code Car class: 3 person-days
Describe Customer use case: 2 person-day