How many of you are recording their historical project-data - for future estimates and how are you doing it?

When working on a project - I always estimate my tasks and calculate how long it will take me to finish. So in the end I get a time-span in which the project should be finished (it rarely is).

My question is - do you record your data and assumptions use in your estimates during a project and use them for later projects or refined estimates on the same project?

If so - how do you record such data and how do you store them?

I used an excel-sheet - but somehow (cannot imagine how that happened ;)) I tend to forget to fill in new assumptions or gained information. On the other hand it is not really readable or useful for evaluating my predictions after finishing the project - to learn from it for the next project.

From stackoverflow

• Isn't that what project managers are for? ;)

  Gambrinus : yes - that's true - but they tend not to see the technical-problems that come along with some issue they want delivered and so some of their estimates are truly wrong ;)

  meade : I think self improvement is everyone's job. PM's should be tracking progress and reporting on changes - during the post mortem a comparison of est. vs. actual should come up but rarely does.

• Sounds like what Joel wrote FogBugz for.

• I had a discussion with a friend recently about a pragmatic variation of this, more specifically, the feasiblity of using the coarse level evidence of when code is checked in.

  Provided you work in a reasonably cohesive manner, your checkins can be related, at least through the files involved, to some work units and the elapsed time used to determine an average productivity.

  This fits well with the Evidence-based Scheduling approach included in FogBugz. If you happen to have been spending time on other things to an unusual degree, then in future you will be more productive than the checkin rate suggests. Any error is on the safe side of over-allocating time.

  The main flaw, for me, in an approach like this is that I typically interweave at least two projects, often more, in different repositories and languages. I would need to pull the details together and make a rough allocation of relative time between them to achieve the same thing. In a more focused team, I think repository date stamps may be good enough.