Time Tracking - Part 3

Here's another blog about time tracking. One beef I have with most time tracking systems is that it confuses tracking status of tasks with tracking time. Here's the classic scenario:

• You use MS Project to schedule a feature. Typically this means you have a summary task called "Feature" and several sub-tasks.
• You estimate at all the sub-task levels, which rolls up to be the total estimate for "Feature"
• Now you tell everyone to track time against the assigned tasks, by updating the Remaining and Completed work fields.

Here's the problem:

• Not all time spent on "Feature" is tracked as Tasks. New stuff comes up all the time, and people don't (and shouldn't) update the schedule to reflect every new thing they discovered they had to do. 
• Most of the time, you really only need to track time against the Feature to get all the value out of time tracking. The extra granularity is rarely used and isn't really that valueable.

I believe an ideal system would:

• Allow you to update Remaining work at the task level, so you can still track estimates/status per task
• Allow you to update Completed work at the Feature level, and would be used to track ALL time spent on the feature, not just time associated with tasks.

If I had my way, I would get rid of "Completed Work" from the task field, and have a way to track time at a much high granularity.

Those are my thoughts. What do you think?

Comments

• Anonymous
  May 17, 2007
  Hi Gregg, We have a similar predicament. A developer does some work on a Feature, completes it, it goes to the client. The client plays with it, raise any changes or updates, which we do and then redeploy. We struggled to accurately estimate the resolution effort involved. No matter how much testing we do, clients always want changes / updates / tweaks. One way we were thinking of tackling this was to have an extra work item 'bucket' per feature called something like Client Updates and set it to a percentage of the overall effort. We could create a different work item type to track this effort. We could then do analysis over time to fine tune what percentage of overall effort this would be, potentially depending on things like client (how likely they are to make updates and to what extent), complexity of the UI / DB etc, developer and so on. This has a few advantages:

• Planned tasks still get Completed work tracked, and hence we can see how accurate our task level estimates are
• The 'extra' work is easily identifiable by the work item type for later analysis for improved future estimates This model would work in TFS now, without many changes (only to add a separate work item type). Thoughts? Cheers, Karl

• Anonymous
  November 07, 2007
  The comment has been removed