From Alan (a thread on agile project management forum):
Now as to the why-bother:
1. Government reports require (a) a summary and explanation of R&D activities, and (b) an auditable tally of hours spent doing this.
2. To develop some basis for estimation, I need to know how much effort goes into development. My time is very irregular, and I honestly have no idea how many hours are put into programming on any task. I don’t know if it varies from week to week. I don’t know how long it will take to finish a project AT ALL.
I am suggesting that tracking hours is but one small wee part of estimation… and it must be combined with other, larger pieces of the puzzle to impact estimates. Unless of course, your work is repetitive and non-thinking. Like stamping out license plates.
Though you can certainly have everyone track hours & tasks to the minutest detail… what is the other unit of measure? Lines of code? Features? Story Points? That is, will you strive to be able to predict Lines of Code per hour? Hours per feature? Days per Story Point?
See rest of post here:
Also, how do you estimate the work being done? Hours won’t give you an idea of productivity. In government the PMA wants essentially a SLOC count because they are only concerned with the end product and it is a measure of change. Unfortunately, it’s not a very good one.
I would always modify the actual SLOC count with other metrics that measure complexity, cohesion, coupling, and about 30 others each weighted according to importance and compared against the industry standard levels. With this modified SLOC I could calculate rough hours given past performance, add some padding or management reserve, and provide a far better estimate.
Additionally, a wise man once mentioned to me that its far better to provide a range than a number and the earlier you are in the “cone of uncertainty” the greater the range. This gives you the ability to manage expectations (didn’t think I was listening to you did you Jon?).
Furthermore, you cannot manage productivity through metrics and past performance with direct calculations as individuals will improve and the team will also change by the time your estimate become reality. Try it with a 40% turn-over rate and 3 month lead time to get a new team member productive.
As a manager, I would estimate and try greatly to not manage an individual’s productivity through metrics. I feel it is better to watch the team’s productivity and only use this towards bettering the estimation process and monitoring any training needs.
John Lamb
Sr Principal Software Engineer
L-3 Communications