We, as programmers, are constantly being asked 'How long will it take'?

And you know, the situation is almost always like this:

• The requirements are unclear. Nobody has done an in depth analysis of all the implications.
• The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the thins you might have to refactor.
• You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.
• The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?
• No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Many of these are organizational or cultural issues that are not simple and easy to solve, but in the end the reality is that you are being asked and they are expecting you to give a reasonable estimate as an answer.

As a result, I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again. But it does.

What is your personal process for deciding and delivering an estimate? What techniques have you found useful?

We, as programmers, are constantly being asked 'How long will it take'?

And you know, the situation is almost always like this:

• The requirements are unclear. Nobody has done an in depth analysis of all the implications.
• The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.
• You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.
• The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?
• No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Many of these are organizational or cultural issues that are not simple and easy to solve, but in the end the reality is that you are being asked for an estimate and they expect you to give a reasonable answer. It's part of your job. You cannot simply say: I don't know.

As a result, I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again. But it does.

What is your personal process for deciding and delivering an estimate? What techniques have you found useful?