Time Tracking in TFS

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 (11)
  1. Ericga says:

    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.

  2. Gregg’s asking for your feedback on time tracking for software development projects…an issue that brings

  3. kolchak says:

    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 🙂



  4. Willy-Peter Schaub on Redmond Sabbatical – Day 5. Brad Abrams on Orcas Beta1 Success Story The Microsoft…

  5. pinky1018 says:

    I think in an environment where software development is the main business, time tracking is definitely important (for reasons mentioned above, among others).  I think it becomes more difficult to accurately track time in an environment where the software development dept. is "merely" a support team (as opposed to a direct income generator).  Though efficient software development can lead to increased income generated for a company, it’s rarely recognized because of the way software development is viewed in these types of organization (not always priority).  Tracking time on development projects becomes a challenge if your developers are also supporting applications since context-switching is a well-documented time cost.  Capturing actual hours worked becomes a secondary piece of data that management rarely finds time (or reason) to use (at least, in my experience).  

    Again…i think this is the case at companies where software development isn’t the main business (and thus directly and blatantly a direct impact on the bottom line).  I do think that that’s somewhat of a fallacy though, since time I waste switching among projects ultimately DOES impact the bottom line.

    I certainly don’t need one more thing to document (SOX has given me plenty of documentation to do).  My company has a time tracking system that is used to charge our time back to projects (we have billable entities), it’s a hassle to get people to fill that out.  I end up summarizing, and thus losing any amount of detail that might be important to those numbers.  Plus, I can only record 8 hours on a timesheet since that’s technically all I get paid for (lol).  I suppose that makes it less of a time tracker, and more of a project charging mechanism.  heh  

    Very interesting topic!

  6. RossBoe says:

    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.


  7. These are great comments. Thank you very much!

  8. Larry Guger says:

    I beleive that Karl hit it on the head perfectly.  Well stated Karl!

  9. TommyNorman says:

    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.


  10. Enric Lizondo says:

    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.

  11. Marc Schaeffler says:

    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.


Comments are closed.

Skip to main content