If you need to consider the cost of features X, Y and Z, you should estimate them relatively, not by guessing that X takes 2 weeks, Y 3 weeks, and Z 4 weeks.

It’s a different thing to estimate the absolute time it will take to do something than to say something will take two times longer than something else.

PM (project or product manager) needs to compare different tasks. They need decide the value of feature X against the features (Y,Z,Y, U V), and compare the costs.

Usually it is the programmer who can provide most acurate estimations.

This comparison of value of features should be done in both agile and “traditional” projects. Without programmers help it is harder to do cost/value based priorization.

All parties just have to acknowledge that estimations are inaccurate.

It is also revealing to study why estimations were inaccurate. It gives important and interesting insights into the code base, people, feelings and technologies used.

I have seen programmers who try to avoid answering this questions, and it is just selfish because then the PM needs to do his value estimations on bad data.

So go on and admit that you are just wrong on this one, if you can

My main point was that the whole concept of relying on estimations is flawed. That’s why I like more the agile approach, where you do stuff in prioritized order and then someone else can decide when to ship.

It’s impossible to answer the question, how long will it take to get a fixed scope done with a set of resources. That question should never be asked.

@Susana: Great tips. Still, there is a problem with estimates, not said here, that will also affect the agile technique: defining the tasks.
You see, I know broadly what should I do. Then I try to break that into small tasks, hopefully no one more that one day. If it is greater than one day, it is probably a breakable task. If it is too small (1 hour) it may be too unrealistic (usually it takes 2 hours to complete the coding, check it, integrate it, plus all other interruptions you may have during that period).

The most common problem when breaking the task, is that you tend to think on the most important sub-tasks, ignoring some easy or trivial ones that would add time at the end.

The best way of detecting what is keeping the engineer from succeeding with estimates is to keep a log. The developer’s journal is a quick document where the developer writes down the problem faced, and the solution. It helps a lot to reconstruct the work and see what things killed the estimate, plus helps the developer to focus on problem and ends up helping him to discover the solution faster (and helps others that may find the same problem later on). You will find that maybe 2 hours were just right to code, but making that code work due to bugs or problems with other tools, takes 3 additional hours!

Cheers!