Planning the Construction Phase

There are many ways to plan an iterative project. It's important that you develop a plan in order to be aware of progress and to signal progress through the team. The approach to planning I use is based on the techniques in Extreme Programming Explained (Beck 2000).

The essence of building a plan involves setting up a series of iterations for construction and defining the functionality to deliver in each iteration. Some people like to use small use cases and complete a use case within an iteration; others like to use larger use cases, doing some scenarios in one iteration and others later. The basic process is the same. I'll describe it with the smaller use cases.

During planning, I like to consider two groups of people: customers and developers.

Customers are the people who are going to use the system for an inhouse development. For a shrink-wrap system, marketing people usually represent the customer. The key thing is that the customers are the people who can assess the business value of a use case being implemented.

The developers are the people who are going to build the system. They must understand the costs and effort involved in building a use case. So, they must be familiar with the development environment. Management usually cannot play this role, because you need recent technical experience to do this.

The first step is to categorize the use cases. I do this two ways.

First, the customer divides the use cases, according to their business value, into three piles: high, medium, and low. (Note that it's considered bad form to put everything in the "high" pile.) Then the customer records the contents of each category.

The developers then divide the use cases according to the development risk. For instance, "high risk" would be used for something that is very difficult to do, could have a big impact on the design of the system, or is just not well understood.

After this is done, the developers should estimate the length of time each use case will require, to the nearest person-week. In performing this estimate, assume that you need to do analysis, design, coding, unit testing, integration, and documentation. Assume also that you have a fully committed developer with no distractions (we'll add a fudge factor later).

Once your estimates are in place, you can assess whether you are ready to make the plan. Look at the use cases with high risk. If a lot of the project's time is tied up in these use cases, you need to do more elaboration.

The next step is to determine your iteration length. You want a fixed iteration length for the whole project so that you get a regular rhythm to the iteration delivery. An iteration should be long enough for you to do a handful of use cases. For Smalltalk, it can be as low as two to three weeks, for instance; for C++, it can be as high as six to eight weeks.

Now you can consider how much effort you have for each iteration.

Note that you will have made these estimates assuming a developer with no distractions. Obviously, this is never the case, so I allow for that with a load factor that is the difference between ideal time and the reality. You should measure this load factor by comparing estimates to actuals.

Now you can work out how fast you can go, which I term the project velocity. This is how much development you can do in an iteration. You calculate this by taking your number of developers, multiplying it by the iteration length, and then dividing the result by the load factor. For instance, given 8 developers, a 3-week iteration length, and a load factor of 2, you would have 12 ideal developer-weeks (8 * 3 * 1/2) of effort per iteration.

Add up your time for all use cases, divide by the effort per iteration, and add 1 for luck. The result is your first estimate of how many iterations you will need for your project.

The next step is to assign the use cases to iterations.

Use cases that carry high priority and/or development risk should be dealt with early. Do not put off risk until the end! You may need to split big use cases, and you will probably revise use case estimates in light of the order in which you are doing things. You can have less work to do than the effort in the iteration, but you should never schedule more than your effort allows.

For transition, allocate from 10 percent to 35 percent of the construction time for tuning and packaging for the delivery. (Use a higher figure if you are inexperienced with tuning and packaging in your current environment.)

Then add a contingency factor: 10 percent to 20 percent of the construction time, depending on how risky things look. Add this factor to the end of the transition phase. You should plan to deliver without using contingency timethat is, on your internal target datebut commit to deliver at the end of contingent time.

After following all of these guidelines, you should have a release plan that shows the use cases that will be done during each iteration. This plan symbolizes commitment among developers and users. This plan is not cast in stoneindeed, everyone should expect the plan to change as the project proceeds. Since it is a commitment between developers and users, however, changes must be made jointly.

As you can see from this discussion, use cases serve as the foundation for planning the project, which is why the UML puts a lot of emphasis on them.