Estimation, that part of a project every developer dreads…

I was reading the IASA forum and found this article that summarizes a few truths about project estimation. I’ve been more than once haunted by time estimates I’ve given and I tend to be very conservative, to the point of having my estimates always frown upon.

Here are some tenants:

1.    It is relatively easy to estimate what you know.
2.    It is difficult to estimate what you know you don’t know.
3.    It is very difficult to estimate what you don’t know you don’t know.

And here is a thought that makes more sense to me. Having tried waterfall, mandate, wishful thinking from management etc in my many years as developer, this to me makes more sense:

Agile is not an estimation methodology in and of itself, and it does not generally develop estimate in units of time. Instead, estimated units of work are used. The units of work do not directly map to time until you have calculated your team velocity. Once the velocity is determined, it can give you a pretty good idea as to how long it will take to complete your project – that is for the body of work in the project that you know of and understand.

And here is the link to the complete article, it is worth reading every line with attention :)…

Are we there yet?