Thursday, March 20, 2008

Time Tracking from Team System Data

One request that I have had from customers is to use work items for time tracking. Often when new project managers see the work remaining coupled with the work completed fields on the Task work item type they feel that it is a prime candidate for time tracking.

There are a couple of reasons why I try and discourage this:
  1. Tasks were not designed to be used as time tracking mechanisms. The goal is quite different. A task has a workflow associated with it that really should include flowing from one user to another as the state of the task progresses. Time tracking is generally associated with a single user.
  2. Work completed is a cumulative value that is not designed to be associated with a particular date as time tracking generally must be.
  3. Although the information is contained within the warehouse it isn’t designed to be retrieved in a person-date-time entered manner.
  4. A separate record must be kept somewhere if you need to determine how much effort was spent on a particular date or a custom report needs to be developed.
  5. Leave workflow and task tracking in one system and time tracking in another. Hours spent on any given day for a specific task is generally not useful information unless you are billing.

Oh, but I am billing you say! That is exactly what the managers that have asked for this feature are doing as well. Okay, so maybe that is a bit of an exception, however I don’t feel that it is neither a particularly reasonable exception nor a particularly strong one to go about breaking the intent of Tasks.

Despite my misgivings I do try and be a helpful person. That is when I’m not grousing about the perversion of the tool.

So here’s my thought. I am going to build a helpful service that tracks work item changes to provide time tracking information. The outline of the solution will go like this:

  1. Subscribe to every work item change for work items of type Task
  2. Extract the new and original values for time completed
  3. If the values have changed the extract the assigned to user
  4. Using a provider pattern load a time recording module
  5. Submit the assigned to user value and the delta value between the new and original time completed values to the time recording module.

The design of the time recording modules would go like this:

  1. Time recording modules would be based on the ITimeRecording interface
  2. A method would be provided on the interface that accepts the pertinent data
  3. Each module that implements the interface would be specific to the target time tracking system.
  4. Once the module received the time tracking information from the Task it would submit it to the target system.


Currently I am planning on implementing a module that submits to an xml file with a configurable location.

0 comments: