Google
 

up previous next contents
Up: Cost-Estimating Previous: Background Next: Estimating using Work Breakdown   Contents

Subsections

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 technologies that are actually mature, 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. At a 5 Therefore, 4.2 hours/FP times 750 hours is 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

As the productivity rate I assumed (4.2 hours/FP) includes past projects that also include bug fixes, this should be the entire development period, including bug fixes. For this team on previous projects, final acceptance testing has taken an average of 25 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 (75 Getting back to our 18-week project, 75

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.