[c3]

Obsessive metrics are fun.

Knowing how long things took vs estimates is useful for determining the accuracy future estimates.

Having an absolute sense of numbers for types of projects is useful for estimating future projects of similar scope; where by absolute I mean, not, "I think it took two weeks last time we did this".

[arethuza]

For that kind of approach to work you'd have to be doing a lot of tasks/projects that are practically identical. I've never worked anywhere (from academic research, to startups to large companies) where any one "project" had enough commonality with others that this approach would generate any value - although I keep seeing generic PMs trying to apply it and failing over and over again.

Of course, it's a good idea to investigate why expected timescales differed from expectations - but IMHO detailed time recording isn't the way to do that.

Of course, YMMV.

[jms_]

When it comes to startups I'm not sure you can prioritise things like this over actually working on your product.

Also, if you're measuring and refining your estimates, they stop being 'estimates' and become something far less useful. If you have problems with estimates being inaccurate, try not estimating.

There are far more interesting metrics to measure rather than flogging a dead horse.

[Mamady]

I agree - time tracking on a granualar level is very high friction and ends up being a waste of time. Better to focus on things that bring more ROI, like product.

Unless your billing on an hourly basis, chances are that counting hours is too much micromanagement.