Project Stages and Baselines

In projects with complex domains or large application systems, story cards may not be sufficient as a discussion basis for the planning game. In such cases, we need additional techniques to get the overall picture especially for the contingencies between the story cards. If one story cannot be developed in the estimated period of time, it may be necessary to reschedule dependent stories. We may also need to divide the bulk of story cards in handy portions and make our planning more transparent to the users and the client. We have therefore enhanced the planning game by selected document types of the tools-and-materials approach [Roock+1998]): baselines and project stages.

We use project stages and baselines for project management and scheduling. A project stage defines which consistent and comprehensive components of the system should be available at what time, covering which subgoal of the overall project. Project stages are an important document type for communicating with users and clients. We use them to make development progress more transparent by discussing the development plan and rescheduling it to meet users' and client's needs.

Table 46.1 shows an example of three project stages (taken from the JWAM framework development project).^[1] We specify at what time we wish to reach which goal and what we have to do to attain this goal. Typically, the project stages are scheduled backward from the estimated project end to its beginning, with most important external events and deadlines (vacations, training programs, exhibitions, project reviews, and marketing presentations) being fixed when projects are established.

^[1] See http://www.jwam.org.

Table 46.1. Example of Project Stages

Subgoal	Realization	When
Prototype with Web front end is running.	Presentation of prototype for users	3/31/00
Prototype supports both Web and GUI front end.	Presentation of extended prototype for users and client	5/16/00
First running system is installed.	Use of Web front end by pilot Web users	8/30/00
…	…	…

Unlike the increments produced during an XP iteration, the result of a project stage is not necessarily an installed system. We always try to develop a system that can be installed and used as the result of every project stage, but we know that this is not always feasible. In large projects or complex application domains, developers need time to understand the application domain. During this period, developers may implement prototypes but rarely operative systems. We thus often have prototypes as the result of early project stages. Another example here is the stepwise replacement of legacy systems. It is often appropriate to integrate the new solution with the legacy system to manage risk. Project stages then produce systems that can and will be used by users. But the project team may also decide not to integrate the new solution with the legacy system, perhaps because of the considerable effort required for legacy integration. In such cases, the project team will also produce installable increments, but it is clear that the increments will not be used in practice. Users are often reluctant to use new systems until they offer at least the functionality of the old system.

Baselines are used to plan one project stage in detail. They do not focus on dates but define what has to be done, who will do it, and who will control the outcome in what way. Unlike project stages, baselines are scheduled from the beginning to the end of the stage.

In the baselines table (as shown in Table 46.2), we specify who is responsible for what baseline and what it is good for. The last column contains a remark on how to check the result of the baseline. The baselines table helps us identify dependencies between different steps of the framework development (see the What For column). The last three columns are the most important ones for us. The first column is not that important, because everybody can, in principle, do everything (as with story cards). However, it is important for us to know how to check the results to get a good impression of the project's progress. The second and third columns contain indicators for potential reschedulings between the baselines and help us sort the story cards that are on a finer-grained level.

The rows of the baselines table are often similar to story cards, but baselines also include tasks to be done without story cards. Examples are "Organize a meeting," "Interview a user," and so on.

The way project stages and baselines are actually used depends on the type of development project in hand. For small to medium-sized projects, we often use project stages but no explicit baselines. In these cases, we simply use the story cards of the current project stage, complementing them with additional task cards. If the project is more complex (more developers, developers at different sites, and so on), we use explicit baselines in addition to story cards. If the project is long-term, we do not define baselines for all project stages up front but identify baselines for the current and the next project stage. Because a project stage should not be longer than three months, we work on a detailed planning horizon of three to six months.

Table 46.2. Example of Baselines

Who	Does What with Whom/What	What For	How to Check
Roock	Prepare interview guidelines.	Interviews	E-mail interview guidelines to team.
Wolf, Lippert	Interview users at pilot customer.	First understanding of application domain	Interview protocols are on the project server.
…	…	…	…
Roock	Implement GUI prototype.	Getting feedback on the general handling from the users	Prototype acceptance tests are OK; executable prototype is on the project server.
…	…	…	…

It is often a good idea to sketch the entire system as a guideline for the project stages. We describe the concepts of core system and specialized systems in the next section, to provide an application-oriented view of the system architecture.