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 (2)
  1. kolchak says:

    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).




  2. jnsnfl says:

    Time Tracking Parts 1-3 have too narrow a focus in my opinion.

    From 25 years of experience starting as a low-level or system level programmer working my way up through the development organization into management I’ve experienced the disorganized use of "time management" much of how you’ve described it.   The premise of this disorganization stems from the reason time management is engaged by "the company".

    Either the company needs to know how many hours you worked to pay you, or they want to know how much it takes to get the work done.  These are not mutually inclusive nor exclusive thoughts and should be discussed on another blog if you’d care to crank that up.   Suffice to say companies have varying reasons, good and bad, to record time, whether it be for the forecasting of work, micromanaging developers, determining what to pay and a plethora of others.

    With regard to using TFS as the IT or development time keeping system the opportunity exists for the effort expended to be recorded in a directly used tool.  

    The biggest hurdle for companies is having a single common interface that people use everyday easily and effortlessly collect time information.

    This is where using TFS falls into place.  Whether the company wants to micromanage or use it for improving their estimating or providing a better understanding of their future.  Granular collection of development time, x time spent on this work-item task and y time spent on this other work-item task,  are used to both represent specific breakdown and rolled-up time.  This can be pushed to other reporting tools or exported to another system without having the IT/Development resources have to use multiple systems.

    SO I ask the question, why, IF I am an IT services group (private, public, direct sales or support oriented) wouldn’t I want to use TFS (since it reflects effort to production) to help me manage time from this group of resources.

    This is a major reason why companies and service organizations ask for it!

    Just my thoughts mind you….

Comments are closed.

Skip to main content