Teams WIT Tools

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.

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

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

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

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!

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

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

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