Take the 2-minute tour ×
Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. It's 100% free, no registration required.

Our team has repeatedly tried to implement time-tracking tools to help us more realistically estimate the effort required for our development projects. Unfortunately, regardless of the tools we try, we find it very difficult to get the team to use them. As such, our estimates tend to be very bad, resulting in our team having to work even hard to meet our deliverables.

I'm curious what others have done to encourage their teams to more closely track their time. I don't want to be heavy-handed or draconian about it, we want our team to want to track their time.

share|improve this question
add comment

2 Answers

I'm not sure if you have found something to work for your team Wally but I just came across this article - "Angry Productive Birds" - that has an interesting concept. And with the angry birds craze these days it just might catch their attention - and make time tracking... well, fun! We have been using TSheets as our mobile time tracker which has been very successful and I think having visual reports of your accurately tracked time in the Angry Productive Bird format it very well could eradicate your time tracking troubles!! Good luck :)

share|improve this answer
add comment

The thing that has helped us improve our estimates is not directly related to accurate time tracking, but has been utilizing the agile processes of two week iterations and "planning poker". We use planning poker to estimate each issue we assign to an iteration. You can google it for further details. The basic idea is each team member flashes a card at the same time and that is their estimate for how long the issue will take. Making everyone flash the card at the same time is important as it prevents junior developers from waiting to see what the senior people say. If there are major discrepancies we then discuss them and re-estimate.

The unit we use to estimate is an "ideal day". This is not a concreate unit, but a concept. It is defined as how much work could you get done in one day of coding with no interruptions. This may or may not really equate to a calendar day, but in the long run it doesn't matter. After a few iterations your project will develop a certain velocity you can track and you'll know roughly how much work you can get done in two weeks.

If you don't want to adopt these sort of development processes another thing we have found that works well is the concept of "information radiators". Basically you just have a TV or computer monitor in a common area displaying various metrics related to the project that you want to improve. You have to be careful with this in the sense that you can't use the metrics in a punitive manner and you want to structure them so that if the developers game the metrics the result will be positive. Not using the metrics for raises, bonuses, etc. will decrease the likely hood that the metrics will be gamed, but structuring them correctly can eliminate the concern entirely.

It seems when people just see these metrics day to day there is some unspoken human need to improve them. Similar to how some people seek badges in forums such as this!

share|improve this answer
    
I also use planning poker, proving it out currently. –  dbobrowski Sep 18 '12 at 12:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.