Estimates Longer Than Three Days Considered Harmful

This is about how to estimate software projects.

Some propose to use function points, others use CoCoMo, others estimate using the number of pages (or screens), then multiplying that number by 2 days/page/person. So for example a 30 page project takes 30 * 2 = 60 days/person, that is an estimation of the cost before asking any developer how much it would cost.

When real developers are sat between keywords and chairs, you may well give them your estimate or you may ask them how long it would take. Since developers tend to say it will take longer anyway, you may cut their estimate by half or you may cut yours by half. This is a known AntiPattern.

A solution to this AntiPattern is to use a TaskDatabase. Tasks are entered into a TaskDatabase. All task can be divided. The manager asks that all task whose estimates take longer than 3 days, be divided. The estimate of the original task must not include the estimates of the child tasks. The benefit is that for short tasks developer estimates are a lot more accurate, especially when they are used to estimate so many tasks and they compare their estimates with the real results.

Then the TaskDatabase automatically calculates how long the project will take.

-- GuillermoSchwarz

Another half-baked and unsigned rant. The author is very kindly asked to consider carefully EvilIsEvil, to further elaborate the rather preposterous claim (as it stands now), or withdraw it, or put some kind of substance into it.

Agreed, especially as it seems to be oxymoronic; you can't solve the "you can't predict more then three days in advance" problem by "break down the project into tasks that take less then three days, then plot them on a calendar", which this seems to propose, as that is a method for predicting things longer then three days correctly. Since I'm of the mind to agree that it's more impossible then possible, I submit that the proposed solution is little better then the original technique of pulling numbers out of the air. In a way, this makes things worse: You're still pulling meaningless numbers out of the air, but now you're spending a lot of time making the meaningless numbers up. Might as well skip the part where you write down in exquisite BigDesignUpFront detail exactly how long the project will take.

I need some help here. When I say no task should take longer than 3 days and that any task may be subdivided in more tasks, I'm trying to say that the original task does not consider then length of its subtasks in its own estimate. In other words, if task 1 is subdivided in tasks 2, 3 and 4, then the estimate for task 1 should only consider the time it would take to finish task 1 as if task 2, 3 and 4 were already done. This is very useful for thinking about completion of the project, even when there is nothing finished.
Is this BigDesignUpFront? It may well be, but it is not required. Actually you don't need a TaskDatabase once you have finished the BigDesignUpFront, but what I propose is to use the TaskDatabase for the whole duration of the project. There is even an agile methodology called Scrum which uses the very same concept.

I'm not the author of the original rant, but here's a tidbit that you may find interesting. On many of my XP projects, my teams have estimated in terms of IdealHours?. We also tracked time spent on each task very exactly (but only in terms of IdealTime). This allowed me to learn all kinds of interesting things about estimate accuracy.

I learned from that experience that tasks of six ideal hours or less were generally completed exactly to estimate. Tasks that had been estimated longer were often wrong. Sometimes they were much less than expected; more frequently they were much longer (often running two to three times the original estimate).

In no case did we take on tasks that were estimated at more than a day and a half (ideal time), so I don't have data on longer tasks. I suspect it would be worse.

-- JimShore

I've seen more pathetic cases. Estimates of a task taking 2 weeks that actually take more than 2 months and produce nothing at the end. Developers reluctant to reduce the estimates or reestimate the tasks that are taking too long. Project managers unwilling to reassign tasks. Projects failing miserably, even when the developers were not incompetent.

Jim, I'm interested to know how you tracked "actual" IdealTime. -- KeithBraithwaite

On the back of each EngineeringTask card, people wrote down when they started and stopped working on each task, including interruptions, at a granularity of 15 minutes. It sounds like a pain, but in actuality it only took a few seconds. For a while, I tracked this very closely, so I'm pretty sure the accuracy was +/- 30 minutes. -- JimShore

Ummm... what about interruptions nested 3 to 5 deep? Or were you fortunate enough that no-one experienced that?

When a pair was interrupted, they would "clock out" of the card by writing the time on the back card. Further interruptions wouldn't make any difference. When all of the interruptions were done and they started work on the card again, they would "clock in" by writing the time on the back of the card. We also had a SupportSwami dedicated to shielding people from interruptions. -- JimShore

See TaskDatabase.