Let’s face it, everyone fails at software estimation including yours truly. It’s probably the least understood part of software development simply because the uncertainties in
This post will not deal with software estimation directly. Instead, it will show you the graphs related to software estimation that you should be familiar with. All of these graphs come from Steve McConnell‘s wonderful book Software Estimation: Demystifying the Black Art; the first group of graphs were copy-pasted from the free Construx presentations while the rest of the graphs were drafted using MS Paint.
The Cone of Uncertainty
The graph above shows the uncertainty regarding estimates done during various phases of the project. For example, an estimate at the start of the project can be anywhere from four times smaller to four times larger than the actual final effort. The uncertainty will go down as you go along the process, e.g. once you finish gathering the requirements, that uncertainty goes down to around +/- 50%.
One thing to note about this graph is that for this cone to hold, the members of the project must continually re-evaluate and re-estimate the project, managing uncertainties as needed. Failing to do so results in the following:
This graph shows an uncertainty cloud, the result of not managing the sources of uncertainties e.g. vague requirements, technical risks, etc. This in turn results in some scary situations: a project that has declared that they have already finished the detailed requirements but still has an uncertainty factor of 2 almost guarantees that the project will not meet its deadline (i.e. it’s still likely that the project will take twice as much time to finish).
The next figure shows what happens to the cloud when the team attacks it during the initial phases of the project. The cloud might get wider later on via unforeseen circumstances, but at least it’s not as problematic as the previous graph.
Effect of Accuracy to Cost, Effort, and Schedule
Long story short, it’s better to overestimate than underestimate.
But of course, misguided managers want developers to finish their tasks ASAP so they want them to underestimate their tasks. A common approach would to tell the team that the project needs to be finished in 2 months while in reality the deadline is 3 months, thinking that the 1 month buffer would allow them to fix the mistakes they made when they rushed.
As we can see from this graph, that approach is a bad idea.
By rushing the project, you create a lot more defects on the way, not to mention that you unnecessarily stress out your team. It is quite common to see the scenario above end up taking 4 or 5 months to finish because of the extra effort needed to deal with the problems caused by rushing. In other words, a bad case of Technical Debt.
Developer’s Estimate
Many inexperienced managers think that when a developer gives an estimate, the developer is talking about a clean bell curve like the graph above. Maybe with a bit of OT, we can make him finish in half the time.
WRONG!
The graph actually looks like this:
Note the “Impossible Zone”, a time range wherein the developer could not possibly deliver a properly working module or program. If a manager forces the developer to go within that zone, the two will inevitably end up with a half-baked and buggy program. This corresponds to the exponential increase of effort in the previous graph when tasks are underestimated.
This graph also shows the weakness of fixed-point estimates. In reality, it’s highly possible to finish programs one or two days early or late. Without taking into account these ranges, managers are stuck with spreadsheets filled with unreliable fixed-point estimates.
A better approach would be to use ranged estimates.
So instead of developers saying “I’ll probably finish it by Wednesday”, you’ll have them saying “I’m fairly confident (> 50%) that I can finish it Tuesday the earliest and Friday morning the latest”. Not only is this more accurate (the shaded area says so), it also makes the project’s schedule more flexible. Ironically, by accepting uncertainty, we reduce the overall uncertainty of a project.
—
So there you have it, the basic graphs in software estimation.
