The scope of an iteration is driven by four factors:

• the top risks to the project
• the functionality required of the system
• the time allocated to the iteration in the Project Plan
• the phase and its specific objectives (See Concept: Phase)

In the initial planning of an iteration, enough work is selected to fill the time already planned for the iteration - although the Project Manager is permitted some latitude to account for resource constraints and other tactical considerations at the time the Iteration Plan is being developed. Obviously, work planned for the previous iteration, but not completed (because the previous iteration's scope was reduced to meet the schedule) will normally have high priority.

The scope of work has also to be driven by a sensible approach to the maximum staffing level that can be applied, in the duration of the iteration, for its completion. For example, it is not usually possible to double the work completed in an iteration by doubling the staff applied to it - even if those resources were available. The approximate staff numbers that can be efficiently applied are determined by overall software size and architecture, and estimation models such as COCOMO II (see [BOE00]) can provide these.

The execution of an iteration is then managed by timeboxing - that is, the scope and quality (in terms of discovered defects not rectified) are actively managed to meet the end date.

In the Elaboration Phase:

There are three main drivers for defining the objectives of an iteration in elaboration:

• Risk
• Criticality
• Coverage

The main driver to define iteration objectives are risks. You need to mitigate or retire your risks as early as you can. This is mostly the case in the elaboration phase, where most of your risks should be mitigated, but this can continue to be a key elements in construction as some risks remain high, or new risks are discovered. But since the goal of the elaboration phase is to baseline an architecture, some other considerations have to come into play, such as making sure that the architecture addresses all aspects of the software to be developed (coverage). This is important since the architecture will be used for further planning: organization of the team, estimation of code to be developed, etc.

Finally, while focusing on risks is important, one should keep in mind what are the primary missions of the system; solving all the hard issues is good, but this must not be done in detriment of the core functionality: make sure that the critical functions or services of the system are indeed covered (criticality), even if there is no perceived risk associated with them.

From the Risk list, for the most damaging risks, identify some scenario in some use case that would force the development team to "confront" the risk.

Examples

• if there is an integration risk such as "database D working properly with OS Y", make sure you include one scenario that involves some database interaction even very modest.
• if there is a performance risk such as "time to compute the trajectory of the aircraft", make sure you have one scenario that includes this computation, at least for the most obvious and frequent case.

For criticality, make sure that the most fundamental function or services provided by the system are included. Select some scenario out of the use case that represent the most common, the most frequent form of the service or feature offered by the system. The Software Architecture Document is used to drive this effort, providing a prioritized set of Use Cases or sub-flows of use cases, selected by the Software Architect to reflect the architecturally significant use cases or scenarios.

Example

• for a telephone switch, the plain station-to-station call is the obvious must for an early iteration. This is far more important to get right than convoluted failure modes in operator configuration of the error handling subsystem.

For coverage, towards the end of the end of the elaboration phase, include scenarios that touches areas that you know will require development, although they are neither critical nor risky.

It is often economical to create long, end-to-end scenarios that address multiple issues at once.

The danger is often to get the scenarios to be too "thick", i.e., trying to cover too many different aspects, and variants, and error cases (See Iteration Plan)

Also, in the elaboration phase, keep in mind that some of the risks may be of a more human or programmatic nature: team culture, training, selection of tools, new techniques etc. and just going through iteration is mitigating these risks.

Examples

1. Create one subscriber record on a client workstation, to be stored in the database on the server, including user dialog, but not including all field, and assuming no error is detected.
   Combines some critical function, with some integration risks (database and communication software) and integration issues (dealing with 2 different platforms). Also force designers to become familiar with new GUI design tool. Finally produces a prototype that can be demonstrated to user for feedback.
2. Make sure up to 20,000 subscribers can be created, and access to one is not longer than 200 milliseconds.
   Addresses some key performance issues (volume or data, and response time), that may dramatically affect the architecture if not met.
3. Undo a change of subscriber address.
   A simple feature that forces designers to think about a design of all "undo" functions. This may in turn trigger some push-back to the users about what can be undone at reasonable cost.
4. Complete all the use cases relative to supply-chain management.
   The goal of the elaboration phase is also to complete the capture of requirements, maybe also set by set.

In the Construction Phase:

As the project moves into the construction phase, risks remain a key driver, especially as new, unsuspected risks are uncovered. But completeness of use case start to be a driver. The iterations can be planned feature by feature, trying to complete some of the most critical ones early so that they can be thoroughly tested during more than one iteration. Towards the end of construction, robustness of full use cases will be the main goal.

Example

1. Implement all variants of call forwarding, including erroneous ones.
   This is a set of related features. One of them may have been implemented during the elaboration phase, and will serve as a prototype for the rest of the development.
2. Complete all telephone operator features except night service.
   Another set of features.
3. Achieve 5,000 transactions per hour on a 2 computer set-up.
   This may step up the required performance relative to what was actually achieved in the previous iteration (only 2,357/hour)
4. Integrate new version of Geographical Information System.
   This may be a modest architectural change, necessitated by some problem discovered earlier.
5. Fix all level 1 and level 2 defects
   Fixes defects discovered during testing in the previous iteration and not fixed immediately but deferred.

In the Transition Phase:

Finishing this generation of the product is the main goal. Objective for an iteration are set in terms of which bugs are fixed, which improvements in performance or usability are included. If features had to be dropped (or disabled) in order to get in time to the end of construction (IOC milestone, or "beta"), they may now be completed, or turned on, if they do not jeopardize what has been achieved so far.

Examples

1. Fix all severity 1 problems discovered on beta customer sites.
   A goal in term of quality, may be related to credibility on the market.
2. Eliminate all startup crashes due to mismatched data.
   Another goal expressed in terms of quality.
3. Achieve 2,000 transactions per minute.
   Performance tuning, involving some optimization: data structure change, caching and smarter algorithm.
4. Reduce the number of different dialog boxes by 30%.
   Improve usability by reducing the visual clutter
5. Produce German and Japanese versions.
   The beta was produced only for English customers by lack of time and to reduce rework.

Each iteration results in an executable release. The release is not generally production-quality (except in the final Transition iteration), but it can be evaluated nonetheless.

Evaluating Inception Iterations

The Inception iteration generally focuses on proving the concept of the product and building the support necessary to approve project funding. As a result, the Iteration release is generally a functional proof-of-concept prototype which lacks real implementation code under a thin veneer of user interface. The evaluation criteria are oriented toward user acceptance and qualitative measures.

Under some circumstances, key technical hurdles must be overcome in inception before product funding is provided; if so, the evaluation criteria must reflect this.

Evaluating Elaboration Iterations

Elaboration Iterations focus on creating a stable architecture. As a result, Elaboration evaluation criteria must focus on assessing the stability of the architecture. Measures that can be used are:

• Interface stability (or breakage)
• The rate of change in the Architecture (compared to an architectural baseline)
• performance of key functionality

The key goal is to ensure that changes during the Construction phase do not ripple throughout the system, causing excessive re-work.

Evaluating Construction and Transition Iterations

Construction and Transition iterations are measured along traditional software testing and change management dimensions such as breakage, defect density, and fault discovery rates. The focus in these iterations is finding errors so that they can be fixed.

Errors are discovered in a number of ways: inspections and code reviews, functional tests, performance tests and load tests. Each technique is oriented toward discovering a particular set of defects, and each has its place. Specifics on these techniques are discussed in the Rational Unified Process Test discipline.

Based upon the goals of the iteration, the set of tasks to be performed during the iteration must be selected. Typically, each iteration will make a partial pass through all the tasks in the software lifecycle:

• Use cases and scenarios are selected which exercise the required functionality
• The use case (or scenario) behavior is researched and documented
• The behavior is analyzed and allocated amongst subsystems and classes which provide the required behavior
• The classes and subsystems are designed, implemented and unit tested
• The system is integrated and tested as a whole
• For external releases (alpha, beta, and general availability) the product is packaged into a releasable form and transitioned to into its user environment.

The degree to which these tasks are performed varies with the iteration and the phase of the project. The individual disciplines (Requirements, Analysis & Design, Test, etc.) define the generic tasks, which in turn are tailored to the organization during process configuration.

Identify affected work products and tasks involved

Once the scenarios or full blown use cases to be developed (plus defects to be fixed) have been selected and briefly sketched, you need to find what are the work products that will be affected:

• Which classes are to be revisited?
• Which subsystems are affected, or even created?
• Which interfaces are probably to be modified
• Which documents have to be updated

Then extract from the process disciplines the tasks that are involved, and place them in your plan. Some tasks are done once per iteration (example here), some have to be done once per class, per use case, per subsystem (example). Connect the tasks with their obvious dependencies, and allocate some estimated effort. Most of the tasks described for the process are small enough to be accomplished by one person, or a very small group of persons in a matter of a few hours to a few days.

It is likely the case that you discover there is not enough time in the iteration to accomplish all this. Rather than extending the iteration (hence either extending the final delivery time, or reducing the number of iterations), reduce the iteration ambitions. Depending on which phase you are in, make scenarios simpler, eliminate or disable features.

Once the set of tasks for the iteration have been defined, they must be assigned to individual project team members. Depending on the staff resources available and the scope of the iteration, the tasks may either be carried out by a single individual or a team. Reviews and Inspections are, of course, inherently team tasks. Other tasks, such as authoring use cases or designing and implementing classes, are inherently solitary (except in the case where a junior team member may be teamed with a senior team member who acts as a mentor).

In general, each work product must be the responsibility of a single individual, even if the work is done by a team:

• Use cases
• Subsystems
• Classes
• Tests and test plans
• etc.

Without a single point of contact, ensuring consistency becomes nearly impossible.