Estimating using FPA and Hours/FP

(Introductory note: On my web site I've provided several online tutorials regarding Function Point Analysis (FPA), so if you're not familiar with it, I recommend learning about it before you read this section. See the References section of this document (section 9) for links regarding FPA and the International Function Point User's Group.)

Because I've worked with this development team on estimates before, and because they are working with only two new, mature technologies, I can use their productivity rate from previous projects to estimate this project.

For instance, when this team has worked with this form of requirements specification, their productivity rate on other web development projects has averaged 4.0 hours/FP. Some have been as low as 3.7 hours/FP, others as high as 4.5 hours/FP, but 4.0 hours/FP has been the average.

Looking at their data, any time any new technologies have been added to the mix their overall productivity rate has actually decreased, not increased. On subsequent projects their appears to be a slight payoff for the new technologies, but on projects where significant new tools have been added the team has generally slowed down.

Finally, there is the matter of the new developer being added to the team. While some people will argue that this will make the team faster, I disagree, especially initially. I could be more of a pessimist and say that the new developer may in fact slow the team down, but as a general practice, when a new developer is first added to a team, for the purposes of estimating I just treat them as if they weren't there.

Choosing a productivity rate

Looking through the team's historical data, and knowing that two new technologies are being added to the equation, I believe the team will proceed more slowly than their 4.0 hours/FP average and tend more toward their 4.5 hours/FP high. To keep this simple, I'll assume a productivity rate of 4.2 Hours/FP. Multiplying that rate times 750 hours yields a total of 3,150 hours. With four developers on the team (not including the new person), and assuming all four can work on the project simultaneously (a pretty big assumption), I divide the 3,150 hours by four, which leads to 787.5 hours per developer.

(Note: You have to be really careful assuming that you can split a project evenly between a collection of developers. Someone coined the phrase "No matter how hard they try, nine women cannot have a baby in one month." Or in this case, 3,150 developers cannot combine to finish this project in one hour.)

Next, I never assume a 40-hour work week; on longer projects this is much closer to about 35 hours per person. So, 787.5 hours/person divided by 35 hours/week leads to an estimate of 22.5 weeks.

Factoring in acceptance testing

The productivity rate I assumed is based on previous projects, and includes time for bug fixes, so this estimate should be the entire development period for this new project (also including bug fixes).

Regarding scheduling, for this team on previous projects, final acceptance testing has taken an average of 25% of the development time. As an example, assume that the overall time for a previous project was 20 weeks. Looking back at that project after it was finished, I can see that a product was delivered for final acceptance testing at the 15-week mark, or at the 75% mark of the project development time. Since this project is estimated to be 18 weeks, we can assume that the application will be ready for acceptance testing at roughly the 14-week mark (75% of 18 is 13.5, which I'll call 14 weeks).

Exercise: A more conservative estimate

A more conservative estimate is to assume that the velocity of the team will be as low as it has ever been - because of the new technologies - and the actual velocity will be 4.5 hours/FP. As an exercise you can work through numbers with this new rate, and see how they compare to my estimate at 4.2 hours/FP. An important note here is that project velocity and Function Point size are two different things. As mentioned earlier, Function Point size is analagous to the size of a house; it measures the size of an application. Project velocity is a measure of how fast your team can develop an application of that size, in a manner similar to the question, "How fast can a construction company build a 5,000 square-foot house?" (And yes, this is an analogy, and not an exact comparison.)

Up: Cost-Estimating Previous: Background Next: Estimating using Work Breakdown   Contents