So what are the problems associated with using tracking hours? Some of the problems are:

• With agile we only plan to 5 or 6 hours a day (or some other amount depending on what people end up doing). We could ask teams to record “everything” but that is an overhead (tasks for everything like doing email). This is the purview of a “time tracking” system. We could just multiple all numbers by 8/5 to get to something more real, but is this any better than using points which we already have?
• Today I get people asking questions like “well I worked 7 hours on this thing, but we only planned for 5, what do I put in?” My answer has been “you put in how much work you have remaining …”. I expect this is because people still think they want to track time they spent on something, for whatever reason. If we start tracking time we are going to have to reconcile all the “ideal time” discussions with the “real time” happenings and come up with recommendations for these.
• Traditional time reporting is based on guesses. This is because generally people will try to minimize the amount of times they go into the time tracking system. So, for example, at the end of the week, people will go into the system and fill in the time card for the whole week. At best these are good guesses. At worse they are not related to reality at all.
• Traditional time reporting is based on budgets. Why is this bad? If a person on the team knows, for example, that the budget is gone for an area she is being asked to work or an area where she knows there is scrutiny and focus, there is a tendency to put the effort into another bucket to avoid the conversation. This means the data is inaccurate at best.
• One reason we work in points and velocity is that it is faster to produce estimates (bigger or smaller than something we know about) and provides better data (more accurate based on self-leveling of velocity information) than hour based estimates. This allows for faster decision making, using more accurate data, with a better view of the trade-offs. (Note: Some argue that “people convert points to hours anyway - this is an anti-pattern - for more information on this see Why Do We Use Story Points Instead of Hours or Days?)
• “Estimated effort” is highly correlated with actual work time. Since the team produces estimates to help them make good commitments, and since there is constant feedback on how well they were able to meet commitments (at the end of Sprints) agile practices help teams drive toward high correlation between estimation points and actual time.
• To me easier approach for cost is to determine burdened rate of team and use sum of completed versus sum of total for each epic to come up with a cost each team who has worked an epic. After all, we really only care about commitment and completion.

But my biggest issue is the impact of putting this type of system in place from a cultural perspective. People say to me “you know, when we first started agile / Scrum it was great because we could focus on getting the work done. Now we have slowly reintroduced all the bureaucracy we used to have back into the system so our ability to work has decreased.” My view is that this is a natural tendency of organizations – to introduce more and more cruft rather than trying to keep things simple. I think we need to be very careful about putting systems and bureaucracy in place.

Worse than this, time recording takes people out of the mode of producing value and, in the worst cases, forces people to focus on creative ways to make time reports look real (or more accurately, good). It is sometimes too easy to focus on the question of how much something costs to produce, when the question we really should be driving is “how do we increase the production of value?”

See Can We Trust Story Points as a Measure of Effort? for additional thinking here.