Share via

Time Tracking in TFS

  • Article

From the mind of Gregg Boer: This is the first of a series of my thoughts on time tracking in TFS.

OK, we have heard quite a bit on time tracking in TFS. People have asked when we are putting it in.

You mention time tracking, and you get mixed emotions. Executives feel they need it. Developers and Testers hate doing it. Managers get sick of nagging people to “enter their timesheets”.

In my experience, very few teams actually do it, and if they do track time, even fewer use the data, unless your work is billable. Hardly anyone uses it to actually improve how the engineer software.

Why is that? I think there are three basic reasons why:

· It takes a great deal of infrastructure (tools) to track time effectively. Most teams don’t have this available to them.

· Most project managers confuse time tracking (recording history) with status tracking (predicting future) … so we get things like “Enter your completed work and your remaining work on your tasks”. Time tracking and status tracking are two different things.

· Most people don’t know what to do with the data, even if they did have it. I’ve seen too often were teams track time, but did nothing with the data.

Those are my thoughts, what are yours?

Comments

  • Anonymous
    April 20, 2007
    keyword: "billable" Often work is done (customization for example) at the client request and must be billed. Tracking it is necessary. And just beeing able to add the CustomerId to a task is often necessary. Scenerio, evaluations, or implementation specific work must be linked to a customer and site. Integration between TFS and CRM would be a plus.

  • Anonymous
    April 21, 2007
    Gregg's asking for your feedback on time tracking for software development projects...an issue that brings

  • Anonymous
    April 22, 2007
    This is important to us for 2 main reasons:

  1. Billable - we do work on Time and Materials basis, and if we don't track time, we don't get paid :)
  2. Constantly improving future estimates - this is probably the reason I care most about tracking time. As an example, while some of our projects are T&M, the majority are fix price. Now, we go through some sort of spec'ing phase, and draw up wire frames (we in the web game). The architects and developers then get around a table, and put together estimates on this work. Right now, we have an Excel spreadsheet template we fill in, and publish those Work Items to TFS. Devs track all their hours against work items for the project. With this data we can:
  • We can see how accurate our estimates are. Without this information, you will keep under or over estimating, both of which are bad cases. Under estimation costs us money and we deliver a project late, over estimation make it difficult to win work as you need to be as cost effective as possible.
  • Find developers who constantly miss estimates, and helping them give more realistic estimations.
  • Find areas where developers may take longer than others (someone may struggle with web services for example) and assign work according to developers strengths / weaknesses as well as provide training in weak areas.
  • We also track effort against bugs. This helps us in later projects when we can say a project of similar size and scope needed 15% (for example) of the total time for bug fixes. We can then factor this in in later projects.
  • Our estimates are based on Excel templates that includes all the tasks we need to undertake. With the hour tracking, ALL work HAS to be tracked against a work item so items and activities we missed are added to the TFS project. This help in post project review to improve the detail of our templates because we can add in tasks that may be missing, add data to help the next estimate effort etc
  • Lastly, we publish graphs of developers weekly output, and it can become a little competition between team members. Most of what we learned came from the classic estimation book 'Software Estimation: Demystifying the Black Art'. We also use the TimeThatTaskPolicy on check in now, but better time tracking functionality in TFS is a must to business like mine... Hope this helped :) Cheers! Karl

  • Anonymous
    April 23, 2007
    The comment has been removed

  • Anonymous
    April 23, 2007
    The comment has been removed

  • Anonymous
    April 24, 2007
    Time Tracking is very important to our organization for reasons already mentioned, billing and defining accurate estimates. We want to help our developers learn how to accurately estimate a task. We were very disapointed with VSTS when we saw how it tracked the time. Fortunately we installed the trial before buying but reading the specs of what it does makes it sound much better than it is, as far as time goes anyway. Ross

  • Anonymous
    April 24, 2007
    These are great comments. Thank you very much!

  • Anonymous
    May 13, 2007
    The comment has been removed

  • Anonymous
    July 25, 2007
    We have just started using TFS and the SCRUM Alliance plug-in. Most of us have very little experience with the SCRUM methodology and external factors have really made our approach more of a hybrid. We have had issues with estimation and accurately tracking our time spent on work items. Although tracking hours worked is a bit against the SCRUM/Agile approach, it is for us a necessary evil. We are adding a "Hours Worked" field to the Sprint Backlog Item to use in conjunction with the Estimated Effort and Work Remaining data to report on how accurate our estimates are over time. Our hope is to identify our weaknesses at a staff and task level. Tommy

  • Anonymous
    September 24, 2010
    We must enter time since most of our developers are contractors. We need time tracking to count hours and pay them. The status report is taken from the remaining time.

  • Anonymous
    July 21, 2014
    Not sure if it is OK with you guys here doing some little 'advertisement' - but since I fully go along with the arguments Karl stated above - more than 7 years ago! - I need to add a comment here. We run a development company since quite some years, doing internally SCRUM and anyway had the need for reporting hours. This is real life, as you might have experienced for yourselves. As we did not found any adequate solution on the market, we developed something internal, found out the potential, fallen in love with the idea of having a really full solution and decided to change the whole company into a time tracking producer. Our personal experience is that time tracking is much more than just entering times into a sheet. Same here - nobody likes it, data is in bad quality and nobody gains benefit from it. Fully integrated time tracking means having best quality data, everywhere integrated into TFS, in realtime, with auto update of complete time and remaining time, perfect selfreflection for the whole team  - and all that with best support for developer. We are eating our own "dogfood" and I'm developer by myself, so maybe you like to find out for yourself if the tool might be helpful for professional timetracking in TFS. I'm always happy to get your feedback. So, if you like, have a look at tfs-timetracker.com. Marc