An estimate by any other name...

posted Fri Apr 20 00:21:21 +0000 2007 - permalink

We've been out various estimation techniques for about the last 6 to 8 months. T-shirt sizing (large project, medium project, small project) is a good way to get a project onto the schedule initially (for example, next year we might pencil in one large project, two mediums, and an assortment of small ones). But ultimately, one needs the details.

Given that we have a small team, we estimate that approximately 4 hours a day will be spent coding on any particular project (since we all have to do maintenance, estimation, project post mortems, scheduling, politiking, and documentation). This will probably vary by team size and if you are large enough, the type of team and how many teams you have. Estimation is almost always tackled in pairs, because a lot of the system design is done during estimation.

The general idea when doing the actual estimation is to break down the project into discrete parts and estimate each individually with a worst case estimate, expected estimate, and the best case scenario. This should include rapid debug cycles, but the actual quality assurance piece should be estimated separately. Because we have to break down into discrete elements, if it's a large project we may bring together the entire team to help perform the estimation.

Now that we have raw numbers (worst/expected/best) for the project, we can begin to play with our numbers. Our current method is to take three times the expected, add in the best and worst, and divide by 5 (so (3E+w+B)/5). This is then divided by the expected number of project work hours per day to get the actual number of days the project should take (we always take the ceiling of this value). For multiple developers, divide this number by the number of developers and take the ceiling of that too -- since you've already broken the project down, handing off discrete sections to work on shouldn't be terribly difficult.

One thing it takes a team a little getting used to is the fact that estimation and scheduling is meant to make you better. It's your time trial information as a sprinter (or long distance runner as the case may be). Obviously if you can't hit your estimates and you are unwilling to adapt your estimation or work habits, you probably will need to find a new avenue of employment soon. But if you are constantly improving at estimating and hitting schedules, management should reward positive outcomes and fight for improvement on the negatives. Keeping a track record is the first step to success.

Tomorrow I'll talk a little more about the QA estimation process.