Estimating in Ideal Time might not be ideal

Ideal Time estimates are almost inevitably perceived as estimates of duration leading some (especially managers) to compare the Ideal Time estimates with actual Elapsed Time. Velocity then becomes a measure of efficiency, used to determine how close they are to removing the impediments that the developers encounter everyday. This might make sense, except that Ideal Time is not really about time and the good intentions might actually be detrimental if the developers find themselves explaining why they only got x Ideal Time of work done in x+y Elapsed Time.

The root of the problem is the assumption that the x in the x+y Elapsed Time is the same as the Ideal Time x.

Relative Measures of Size

Story Points
NUTs (Nebulous Unit Of Time)
Gummi bears
T-shirt Sizes

Velocity, and deriving an estimate of duration

By measuring the team's rate of progress (velocity) in terms of the number of size units of work [1] done in an iteration [2], you can arrive at an estimate of duration in terms of the number of iterations required to complete the remaining tasks: remaining size units of work divided by the teams velocity.

Instead of having to think about and account for the inevitable overheads that occur everyday, velocity gives us a way to map ideal time into elapsed time based on historic data.

1. ideal time or a relative measures of size
2. fixed length, comprised of working hours of working days

Ideal Time, an estimate of size

Ideal time (or ideal development time of effort) is the amount of time it will take you to finish a task if you had no interruptions or impediments. It is an estimate of size or effort and has little to do with time, since you rarely ever get contiguous blocks of productive time.

Estimating in ideal time is affected by various factors like the developers own cognitive biases, their skill and experience levels, complexity of the problem, the design of the software, and available tools, to name just a few.

Ideal time can be used to derive an estimate of duration.

See also:
Estimating in Ideal Time might not be ideal

Elapsed Time, an estimate of duration

Traditionally, software developers are expected to give estimates of duration in elapsed time. Elapsed time is the actual time (working hours of working days) it takes to complete a task. This includes time spent on things (inevitable everyday overheads) other than the task at hand.

Estimating in elapsed time is inherently difficult because, apart from the various factors that affect the estimation of effort for a given task, you also need to worry about: distractions and interruptions [1], unexpected events or obstructions [2], and just about anything else.

1. meetings, emails, interviewing candidates, phone calls, reviews, task switching, training, bug fixes, etc.
2. other projects, absences, developer turnover, non-cooperative team members, sabotage, etc.

Accurate Estimates

Accurate estimate is an oxymoron. You might get estimates that are better, never accurate.

Estimation and Targets

For some, estimates serve as targets. Targets set the pace at which work gets done. They change one's relationship with time (you get a lot more work done on the day before going on vacation than on a regular day).

From Fundamentals of Software Engineering (Second Edition) by Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli:

A surprising finding was that, in a controlled experiment, the subjects who had no schedule at all finished their project first, beating out both the group that had an aggresive schedule and the one that had a relaxed schedule. Experiments have shown that engineers, in general, are good at achieving the one tangible goal that they have been given: If the primary goal is to finish according to a given time schedule, they usually will-but at the cost of other goals such as clarity of documentation and structure.

From Software estimation considered harmful by Peter Seibel:

Sometimes we set targets in order to convince others, or ourselves, that something can be done. We may set targets to inspire ourselves to do more, though it’s not clear that’s a winning move, and even less so when managers set a target to “inspire” the folks who work for them. (See DeMarco and Lister’s Peopleware, chapter 3 and the discussion of Spanish Theory managers.) We may also set targets to give ourselves a feeling of control over the future, illusory though that feeling may be. After the fact, a target hit or missed can tell us whether or not we did what we set out to do. However if we missed a target, we can’t know whether that’s because the target was unrealistic or because we didn’t perform as well as we should have. Setting and hitting targets does make it look like we know what we’re doing but we need to keep in mind that targets rarely encompass all the things we care about — it’s much easier to set a target date for delivering software than a target for how much users will love it.

If the goal is simply to develop as much software as we can per unit time, estimates (and thus targets), may be a bad idea. In chapter 4 of Peopleware, DeMarco and Lister discuss a study done in 1985 by researchers at the University of New South Wales. According to Peopleware the study analyzed 103 actual industrial programming projects and assigned each project a value on a “weighted metric of productivity”. They then compared the average productivity scores of projects grouped by how the projects’ estimates were arrived at. They found that, as folks had long suspected, that programmers are more productive when working against their own estimates as opposed to estimates created by their boss or even estimates created jointly with their boss, averaging 8.0 on the productivity metric for programmer-estimated projects vs 6.6 and 7.8 for boss-estimated and jointly-estimated. The study also found that on projects where estimates were made by third-party system analysts the average productivity was even higher, 9.5. This last result was a bit of a surprise, ruling out the theory that programmers are more productive when trying to meet their own own estimates because they have more vested in them. But the real surprise was that the highest average productivity, with a score of 12.0, was on those projects that didn’t estimate at all.

Estimation and Closure

A lot of us are uncomfortable with doubt and uncertainty. Estimation is a way for us to put a fence of certainty around the inherent uncertainty of software development. However, coming up with a date for when a task will be done, does not remove the uncertainty, it just hides it.


From Fundamentals of Software Engineering (Second Edition) by Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli:

Estimation is always accompanied by the risk of being wrong.

Estimation vs. Guessing

Without information and experience you are not estimating, merely guessing.