1

I am not very good at estimating how long a piece of work will take to complete. I am guilty of putting my finger in the air and guessing. Usually things are later than expected, however sometimes they are earlier than expected. For example, a recent individual task was delivered in four months instead of five months. However, I am usually late.

I want to get better at this. If I say something will take four months then I want it to take four months or less and not four and a half months or five months etc.

The next task I am approaching was moved to the top of the project plan within the last week because of external pressures (external to the department). The business area want to know exactly how long it will take to complete. I find it difficult to estimate because of the following reasons:

  1. The system I develop is very complex. I inherited it a few years ago and the previous developer did not follow good practice e.g. SOLID, separating layers (business layer etc) etc.
  2. The business requirements are not particularly well understood by the business area because the system is very complex and we have to take into account legislation, which is only guidance and completely open to interpretation.
  3. We lack the appropriate tools e.g. testing framework, continuous integration etc.
  4. I am a sole developer so I have no-one to really turn to for guidance or help e.g. with testing etc.

Anyway I have read questions like this: How to respond when you are asked for an estimate? and this: http://msdn.microsoft.com/en-GB/library/hh765979.aspx.

My manager has suggested that I spend one month doing the analysis for the next piece of work (it is complex). I think I could do it in a week (I usually only spend a few days). What should the Agile output of an analysis be? How long do you typically spend of analysis?

Community
  • 1
w0051977
  • 7,139

1 Answers1

3

If I say something will take four months then I want it to take four months or less and not four and a half months or five months etc.

Well don't we all? You can't, so don't. Not in the environment you described. It's too unpredictable.

You mentioned agile and it is because of this you don't make promises 4 months in advance at least not until you get some of the project built to use as a gauge for the rest of the project. Then you may have to change that estimate. Everyone has to agree to this type of process; not just the developer.

The business requirements are not particularly well understood by the business area because the system is very complex and we have to take into account legislation, which is only guidance and completely open to interpretation

If you don't know what you have to build, how can you give a solid estimate? Manage expectations, "If the requirements don't change, I can do it in 4 months." Document changes and resubmit estimates. Who knows, maybe they can do without that feature?

I understand you take pride in your work and want to deliver on your promises, but this environment doesn't lend itself to that. Things change and stuff happens - estimates are not immune to these facts.

JeffO
  • 36,956