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.