We have defined an iteration as a rather complete mini-project, going through all major disciplines and resulting in
most cases in an executable, yet incomplete, system: a release. Although the cycle [edit, compile, test, debug] sounds
like an iteration, this is not what we mean here. The daily or weekly builds incrementally integrating and testing more
and more elements of the system may also seem to be an iteration, but that is only a portion of an iteration, as we use
the term here.
An iteration starts with planning and requirements, and ends with a release, internal or external.
How quickly you can iterate depends mostly on the size of the development organization.
Five people can do some planning on a Monday morning, have lunch together every day to monitor progress, reallocate
tasks, start doing a build on Thursday, and complete the iteration by Friday evening.
But this will be very hard to achieve with 20 people. It will take more time to distribute the work, synchronize
between subgroups, integrate, and so on. An iteration may take rather three or four weeks.
With 40 people, it already takes a week for the "nervous influx to go from the brain to the extremities". You have
intermediate levels of management, the common understanding of the objective will require more formal
documentation, more ceremony. Three month is a more likely reasonable iteration length.
Other factors come into play: the degree of familiarity of the organization with the iterative approach, including
having a stable and mature organization, the level of automation the team is using to manage code (for example,
distributed CM), distribute information (for example, internal web), automate testing, and so on.
Be aware also that there is some fixed overhead in an iteration, in planning, synchronizing, analyzing the results, and
So, on one hand, convinced by the tremendous benefits of the iterative approach, you might be tempted to iterate
furiously, the human limits of your organization are going to slow your fervor.
Some empirical data:
Number of developers
Duration of an Iteration
Iterations of more than 6 months probably need to have intermediate milestones built in to keep the project
on track. Consider reducing the scope of the iteration to reduce its length and ensure a clear focus.
Iterations of more than 12 months create their own risk, as the iteration spans the annual funding cycle. A
project which has not produced anything visible in the past 12 months is at risk of losing its funding.
Iterations of less than 1 month need to be scoped carefully. Typically, short iterations are more suitable
for the Construction phase, where the degree of new functionality to be included and the degree of novelty are low.
Short iterations may do little or no formal analysis or design, and may simply be incrementally improving
Iterations need not all be the same length: their length will vary according to their objectives. Typically,
elaboration iterations will be longer than construction iterations. Within a phase, iterations are generally the
same length (it makes planning easier).
Once you have an idea of the number of iterations in your coarse-grained plan, you need to define the contents of each
iteration. It is even a good idea to find a name or title to qualify the product you have at the end of each iteration,
to help people get a better focus.
Example Iterations for a Private Telephone Switch
Iteration 1: local call.
Iteration 2: add external calls and subscriber management.
Iteration 3: add voice mail and conference calls.
A very simple project may have only one iteration per phase:
One iteration in the inception phase, producing perhaps a proof-of-concept prototype, or user-interface mock-up, or
no iteration at all, in the case for example of an evolution cycle.
One iteration in the elaboration phase to produce an architectural prototype.
One iteration in the construction phase to build the product (up to a "beta" release).
One iteration in transition to finish the product (full product release).
For a more substantial project, in its initial development cycle the norm would be:
One iteration in the inception phase (possibly producing a prototype).
Two iterations in the elaboration phase; one for an architectural prototype, and one for the architectural
Two iterations in the construction phase to expose a partial system, and mature it.
One iteration in the transition phase to go from initial operational capability to full product release.
For a large project, with lots of unknowns, new technologies, and the like, there may be a case for:
an additional iteration in the inception phase, to allow for more prototyping.
an additional iteration in the elaboration phase, to allow different technologies to be explored.
an additional iteration in the construction phase because of the sheer size of the product.
an additional iteration in the transition phase to allow for operational feedback.
So over a development cycle, we have:
Low: 3 iterations [0,1,1,1]
Typical: 6 [1, 2, 2, 1]
High: 9 [1, 3, 3, 2]
Very High: 10 [2, 3, 3, 2]
So, in general, plan to have three to ten iterations. Observe though that the upper and lower bounds connote
unusual circumstances, so most developments will use six to eight iterations.
Many variations are possible depending on risks, size, complexity:
If the product is intended for some totally new domain, you may need to add some iterations in the inception
phase to consolidate the concepts, show various mock-ups to a cross-section of customers or users, or build a solid
response to a request for proposal.
If a new architecture must be developed, or there is a large amount of use-case modeling, or there are very
challenging risks, you should plan to have two or three iterations in the elaboration phase.
If the product is large and complex, and developed over a long period, you should plan to have three or more
iterations in the construction phase.
You should plan to have several iterations in the transition phase if, because you must minimize the time to
market, you must deliver the product with a reduced set of functionality, or if you feel you may need a lot of
small adaptations to the end-user base after a period of use.
The default review sequence for a waterfall life-cycle project has a single major review at the completion of the
important work products, for example:
System Requirements Review (SRR), at the completion of the system specification;
Software Specification Review (SSR), at the completion of the software requirements specification;
Preliminary Design Review (PDR), at the completion of the architectural design sections of the software
Critical Design Review (CDR), at the completion of the detailed design sections of the software design
In the Rational Unified Process (RUP), parts of the equivalent work products are reviewed as they are completed in each
iteration, but the major milestones (and therefore reviews) are aligned with the completion of the phases, inception,
elaboration, construction and transition. A Project Manager wanting to adopt the RUP may have to find a way to
reconcile this apparent conflict, because of contractual obligations. Ideally, the Project Manager should convince the
customer that the phase and iteration based approach in fact gives greater true visibility into project progress, and
reduces risk, so that there is no need for an SRR, an SSR, and so forth. However, this is not always possible, and the
Project Manager has to schedule these reviews at appropriate points. It is possible, in the RUP, to locate the points
at which these important work products (actually, their equivalents in the RUP) are essentially complete, although this
does not always neatly align with phases or iterations.
This is done here by assuming that the relative effort that will be spent on requirements, design, and the like will be
approximately the same in the RUP as in the (ideal) waterfall life cycle - but that the effort will be distributed
differently. The result is the following:
the SRR (concerned mainly with the Vision) can be scheduled at the end of the inception phase;
the SSR (concerned mainly with the Software Requirements Specification) at about 1/3 of the way
through the elaboration phase;
the PDR (concerned mainly with the Software Architecture Document) at the end of the elaboration
the CDR (concerned mainly with the Design Model) at about 1/3 of the way through the construction
For efficiency, the Project Manager, in consultation with the customer, should attempt to combine these reviews with
the prescribed RUP reviews. This is clearly possible for the SRR and the PDR, they can be combined with Lifecycle Objectives Milestone Review and the Lifecycle Architecture Milestone Review, respectively.
Just as the software process is influenced by the project's characteristics, so is the project organization. The
default structure presented here (see the figure below), has to be adapted to reflect the effects of factors such as
the ones listed:
The Business Context
The Size of the Software Development Effort
The Degree of Novelty
Type of Application
The Current Development Process
Technical and Managerial Complexity
These are key distinguishing factors when analyzing how the organization as a whole should adopt a new development
process, here we will examine their effect on the choice of project structure. The figure below presents a default
project organization, showing how responsibilities are assigned to the team structure.
Figure showing Default Project Organization. Note that there is no significance in terms of seniority or authority in
the ordering of the roles.
This figure is a starting point for considering how project-level roles and responsibilities should be mapped to a
structure of teams. The figure also serves to emphasize that roles (shown in the yellow boxes) are not individuals, but
"hats" an individual (or a team) can wear in the project. It is for this reason that some roles (the Project Manager,
for example) appear more than once. This indicates that, at some time, the behavior of the Project Manager, as defined
in the RUP, may appear in more than one team. For example, in a large project, the task of preparing a status report
based on a Work Breakdown Structure may be delegated to an individual in the Administration Team. However, this
is a responsibility that the RUP assigns to the role called Project Manager.
In a small project, it is likely that an individual nominated as Project Manager will perform all the tasks of
the role called Project Manager, in which case the Administration Team coalesces with the Software Management
Team. The selection of team structure will be influenced by the nature and size of the project but should be tempered
by some, largely common-sense, rules:
small teams are usually more productive; however, in a large project this has to be balanced against the amount of
deep hierarchies are to be avoided
the span of control of any manager or team lead should be limited to seven plus or minus two
the software development team structure should be driven by
the software architecture; a good architecture, with high cohesion and low coupling between subsystems, will allow
teams to work more effectively in parallel
testing, other than unit test, should ideally be performed by a team separate from the development team. Note,
however, that this may not make economic sense in a very small project
the structure must allow all teams and individuals to be given clearly defined authorities and responsibilities.
This is particularly important if the hierarchy exceeds three levels. The managers and team leads in the middle of
such structures need to understand what is required of them in balancing technical and managerial tasks.
the structure must support the capabilities, experience and motivations of the staff: for example, if a single team
is supposed to perform analysis, design and implementation, without any intermediate hand-off, it will need all the
necessary competencies. Skilled analysts are not necessarily good implementers;
team structures should not be rigid: individuals will migrate between teams over the project's lifetime, and the
responsibilities of teams will change as the emphasis of the project shifts from phase to phase.
The rationale for the default organization is discussed at length in [ROY98]. In
particular, the assignment of responsibilities for deployment to the software assessment team recognizes that, of all
the teams in a development project, the software assessment team has greatest exposure to the software as the user will
During the life of a project, the organization will evolve to support the work breakdown structure captured in the
project plan. This is shown in the figure below, which is taken from [ROY98].
This evolution emphasizes a different set of tasks in each phase:
the Inception team: an organization focused on planning, with enough support from the other teams to ensure that
the plans represent a consensus of all perspectives;
the Elaboration team: an architecture-focused organization in which the driving forces of the project reside in the
software architecture team and are supported by the software development and software assessment teams as necessary
to achieve a stable architecture baseline;
the Construction team: a balanced organization in which most of the task resides in the software development and
software assessment teams;
the Transition team: a customer-focused organization in which usage feedback drives the deployment tasks.
Migration between teams during this evolution will ensure that knowledge and capability is retained in the project. For
example, when elaboration is complete, some architecture team members could be dispersed into the development teams,
perhaps to act as team leads, or carry the architectural 'vision' into development. Later still, towards the end of the
construction phase, the focus shifts to the assessment team, and there is a movement of staff from the development team
into the assessment team. It is also important at that stage, to avoid the loss of architectural integrity in the heat
of construction, that the influence of the architecture team is not allowed to wane as the 'center of gravity' of the
project moves. Moving some architecture team members to the assessment team is one way to do this.