Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How can I encourage my coworkers to track the time they spend resolving issues and implementing features? We have software to do this, but they just don't enter the numbers.

I want the team to get better at providing project estimates by comparing our past estimates to actual time spent. I suspect that my coworkers don't see the personal benefit, since they're not often involved in project scheduling.

share|improve this question
3  
Perhaps the problem is that they have to enter the numbers instead of having the software track the time and just asking them periodically to set the description of the activity and press record. I wrote a program, for myself, to address exactly this, because I would go all day in the zone and then surface and have a hard time generating my "time log" for the day. See softwaremonkey.org/Program/TimeKeeper –  Lawrence Dol Jun 3 '11 at 20:47
1  
Just do to them what was done to me at one company I worked for. Assign him a task, immediately have him spend 3 continuous days in meetings that you attend with him, and then immediately after the meetings demand to know why the task wasn't completed. –  user16764 Jul 27 '12 at 16:31
1  
Where do I put the numbers for the time when I solve a problem on the way home? –  Pieter B Oct 25 '13 at 12:25
    
@PieterB IMO if you regularly spend enough time thinking about work problems in the car that it increases your productivity then I think that time should be tracked for project estimates, even though it's uncompensated. It's time you would otherwise spend thinking at your desk. On the other hand, if it's a one-off revelation in the car, I don't think it's worth tracking since it's not something you would base a project estimate off of. –  M. Dudley Oct 25 '13 at 12:59
    
@M.Dudley I often have revelations in the car, probably because I get away from the tunnel-vision I sometimes get stuck in while in the office and have time to get a more distant view for a problem at hand. Especially XY problems I solve this way. It's not uncommon for me to come in in the morning and solve a problem in 3 lines of code where I spent considerable time trying to solve it the day before. –  Pieter B Oct 25 '13 at 13:05
show 1 more comment

13 Answers

up vote 36 down vote accepted

I suspect that my coworkers don't see the personal benefit, since they're not often involved in project scheduling.

That's fixable.

Make them involved in scheduling.

share|improve this answer
1  
There's a quote about this, but most of my books are still packed away. Something about the engineers themselves being the best at scheduling, so they should be involved in the scheduling of a project from Day 1. I want to say that comes from Steve McConnell's Rapid Development, but I can't be sure. –  Thomas Owens Jun 3 '11 at 13:40
3  
I recently saw on a project of mine (6 month project) where our PM allocated 4 hours for an integration with another application. Suffice it to say the integration will take substantial time and myself and another developer thought this was quite comical. –  Chris Jun 3 '11 at 16:42
    
@ThomasOwens It still baffles me every time I'm told how long something's going to take by a BA or PM. This fallacy is so thoroughly debunked it's saddening to realize it just means none of the BAs or PMs do the slightest bit of reading about the industry they work in. –  Jimmy Hoffa Jan 15 '13 at 20:57
add comment

Try introducing them to personal organization systems like Pomodoro technique for example (there are many others but that's the one I'm trying now)

The technique uses a timer to break down periods of work into 25-minute intervals called 'Pomodori' (from the Italian word for 'tomatoes') separated by short breaks. Closely related to concepts such as timeboxing and iterative and incremental development used in software design, the method has been adopted in pair programming contexts. The method is based on the idea that frequent breaks can improve mental agility..

share|improve this answer
add comment

Good way

Use software, which actually makes that easy and almost transparent, like for example Mylyn. Combine it with tools like for example an hour burn-down chart.

Bad way

Force them to fill in tedious timesheets, where you have to manually specify project, task, exact dates and times etc.

share|improve this answer
3  
I hope you have filled in form tt-proc-1b to record the time spent answering this question, then getting managerial signoff to agree the time spent. and you filled out form tt-est-1a to record the estimated time that you would be spending on answering this question before you started work on answering it? –  gbjbaanb Jun 3 '11 at 15:12
    
mylyn / tasktop... not perfect but sure does a lot towards good time tracking just as a side effect of another tool that brings actual benefits to the programmers directly... not perfect yet blissfully awesome !! –  Newtopian Jun 3 '11 at 18:20
add comment

Any tool that requires programmers to devote even more time away from programming isn't necessarily a great thing. Programmers already have plenty of overhead, they aren't having 5 minute meetings and then coding up a storm.

If you have the power, you can force them to do it. But by far the best solution is to build a seamless tool that makes it painless. I can't tell you how to do it for design, but for coding, you want to log changes made in the development environment. This used to be an impossibly high bar, but if you are using something like Eclipse, it's not that bad, maybe it already exists. This way, you can measure how much time is going into each file, and potentially in Java, each method. That's much finer-grained information than you get by asking them to bill out, and it can be pretty accurate.

Similarly, if you have a tool for entering designs, you can intercept there.

share|improve this answer
add comment

Have you considered using your existing ticket system instead? Our ticket system monitors the time between the creation of a ticket and when it is closed. If you create tickets for tasks and make a ticket number a requirement for committing code, you're getting more bang for your buck.

share|improve this answer
add comment

Track your time or don't get paid. Millions of people do it (consultants, lawyers, etc.), why can't they?

Some might think this is rather draconian, but it's not. If you work at Starbucks, you have to clean the bathroom. If you work at a bank, you wear a suit and tie to work every single day, and if you're a software engineer on a team that needs you to track your time, you do it!

Sometimes we have to do things at our jobs we don't like. We're all big boys and girls, I think we should be able to handle it.

share|improve this answer
1  
Exactly what I was going to say. Especially if you have clients paying the bill - how else can you know what to charge them? I guarantee that one late paycheck because someone didn't load his time would fix the problem forever. –  HLGEM Jun 3 '11 at 17:46
2  
This is an excellent way to get sued for not paying overtime to the employees you're claiming as FLSA-exempt but who don't qualify for exemption because you're docking pay based on performance. –  Wooble Jun 3 '11 at 17:52
1  
@Wooble: Obviously I don't advocate actions that would make you vulnerable to being sued, or in any way mistreating your employees. But the idea is the same. There should be reprecussions for not doing your job. And in many cases, tracking your time is part of your job. So maybe you don't dock pay, but you warn, put on probation, whatever it is that makes sense, but the fact is, you have to do your job. It's selfish not to, because it affects all your team members as well. –  Richard DesLonde Jun 3 '11 at 18:26
    
@HLGEM: Your point is exactly right. If your contract with the client is on a T&M basis, you better track your time, or you are being dishonest. –  Richard DesLonde Jun 3 '11 at 18:28
    
Unfortunately I'm not in a position to mandate any time tracking, so I need to find alternative methods. –  M. Dudley Jun 3 '11 at 18:44
show 1 more comment

Think about why it might be that they don't respond well to this request. Don't just assume that they're lazy or avoiding effort.

Developers who avoid producing evidence are usually

  • Worried about how it might be used and/or
  • Concerned about the validity of the data

This is why points-based estimation and shirt-sizing has taken off in recent years. It takes into account the very uncertain nature of the process of estimation and allows for "magic" (aka, averaging out of the uncertainties) to take control of scheduling.

And, while it may not seem logical, it does mostly work - at least as well as an hour- or day-based system. It is also very difficult to batter a team or individual around the head with what they've achieved in a month if it's done in an arbitrary way.

Scrum also allows developers control over the velocity, which means that they are making a promise to achieve whatever you choose from A, B and C or A, Y and Z. When they've made that promise, developers do not like to fail; but if you make that promise for them, they won't care. It's your fault if it's wrong.

I understand that you're saying you wouldn't use the reestimations in that way, but how sure are the individuals on your team of that?

share|improve this answer
add comment

Obviously the best answer depends entirely on the psychological blend of your team. Are they competitive? Design a recurring contest that rewards the winner for entering their time into the system. Adjust and tune the contest so that the players think it's fair and fun. Make it a game.

Perhaps they're concerned that if there was transparency into how much time they actually spent performing a task, there would be negative consequences. I've always wondered about designing an "effort tracking tool" that was anonymous and where buckets were sufficiently high-level enough that there would be multiple individuals pouring effort-spent amounts into each bucket that individual contributors couldn't be singled out. Even just getting more accurate effort costs for high-level project buckets might be useful data for project planning and overall team velocity, but this would avoid the "OMG, I can't believe Joe took 3x his estimate to do something so simple ..." or whatnot that people are afraid to report in a traditional time-tracking system.

I guess these are just two examples, but really, having a good grasp of the psychological make-up of your team will give you the right answer for how to incentivize or otherwise encourage them to contribute their effort cost information.

share|improve this answer
    
+1 for the transparency thing. I had to do a time tracking system once and I deliberately made it really hard for management to pull out the exact start and end time, instead they could just see total time spent. That way it didn't matter when a staff member did the work, just that it was done and how long it took. A little detail but still. –  James Jun 3 '11 at 22:57
add comment

In my experience, the following are the problems with most time tracking software:

  • The developer does not have the ability or authority to break down a task into more easily estimatable subtasks on the fly.
  • There is no good way to account for subtasks you didn't know about until you started working on something, a situation which comes up all the time in software development and debugging.
  • Time spent is entered after the fact, when it is difficult to remember exactly how much focused effort went into a task and how much went to meetings, colleague's questions, peer reviews, and other overhead.
  • There is no good way to account for non-tracked tasks. At the end of the day, do you put down 8 hours even though 6 of those were spent dealing with meetings and such?
  • There is no good way to account for and communicate uncertainty in your estimates.

I've addressed many of those issues by starting to use the pomodoro technique for myself. If I work 25 minutes uninterrupted on a task, it gets recorded right then, and my estimates are done in terms of those uninterrupted intervals. I'm still working on incorporating evidence based scheduling to communicate the uncertainty, and on translating my own fine-grained tracking into the coarse schedule estimates that PMs like, but it's definitely been an improvement so far.

share|improve this answer
add comment

Joel Spolsky wrote an article on Evidence Based Scheduling that may help you find some arguments.

You have to convince your co-workers that better estimation skills can help them produce better software. Here are some points in favor of tracking task time:

  • If you have an arbitrary management-set deadline, good estimations will tell you what you can actually accomplish in that time. As a bonus you have some nice graphs to convince the manager that you know what you're talking about.
  • You have to think throught the project more carefully. The article that I linked to states, "You have to break your schedule into very small tasks that can be measured in hours." Since you thought about pretty much every facet of the project (hopefully writing a spec!), you are much less likely to be surprised by something you didn't think of.
  • It makes you a better developer. You will see over time what kinds of tasks you tend to underestimate, so you can spend some time getting better at those specific tasks rather than optimizing blindly.
share|improve this answer
1  
+1, for the second point. I've found that any estimates that uses measure of time in days or weeks, will always be inaccurate in terms of days or weeks. If you're off by a few hours, you can always recalculate the other estimates more accurately. And writing a spec, or building a PoC artifact makes for more accurate estimates, although coming up with estimates for those items is not that simple. –  Vineet Reynolds Jun 3 '11 at 13:41
add comment

You can accomplish this in the standard way - carrots and sticks.

The carrot(s) in this case could be "improved future estimation by understanding our current velocity" - but you would have to follow through.

Your comment that they are not often involved in project scheduling may make this a tough sell.

The most high-functioning among them, particularly if you have any followers of PSP, is that you are helping them get better.

The most common stick (to beat them with, not to hold the carrot in front of them) is "it is mandatory, do it". While not much of a motivator; at least the position is clear.

Lastly, is the software you are using contributing to their reticence? Is it clunky? Do they have to look up time-codes in System A, before then put their time in System B? Is it too granular, does it not allow for "off" time and demand an accounting of 8 hours per day. Make it as friction-free as possible to also help adoption.

Good Luck

share|improve this answer
5  
+1 for that last paragraph. Make it easer to do the time tracking than to not do it, and all of a sudden it'll magically get done. –  Scott Jun 3 '11 at 14:31
5  
Great last point - I hated having to look up an 8 digit number when a web-based dropdown could be written in 10 minutes (my estimation using the estimation dice I keep in my desk). Also, I wouldn't use Management Bingo terms like "understanding our current velocity" but rather "you won't have to work lots of mandatory unpaid overtime trying to get things in at the end of the schedule if we make our schedules realistic to start with." –  Wonko the Sane Jun 3 '11 at 18:19
    
@Wonko +1 for "estimation dice" :-) –  sdg Jun 3 '11 at 18:22
add comment

Depends on how and why you want them to track time, also are we just counting the time at the office or the time spent on the commute to work thinking about the problem as well?

Project scheduling is difficult and there is a good chance the metrics you get will not be as useful as you might think they would be. No two problems are the same so one task may take eight hours while another may take 32 hours to finish.

You might want to look into evidenced based scheduling as it has the developer estimate how long a task will take and then adjusts over time based upon how good their estimates are; however, it is not as good for large projects since you may not know all of the tasks up front. For large projects you might be better off looking at past projects of similar scope and using them as a yardstick as opposed to trying to aggregate individual estimates.

share|improve this answer
add comment

If you're not the team lead/PM then you're going to struggle with this one. People don't like to listen to their peers if it requires them to have to do more work than absolutely necessary (in my experience that's the case, anyways). Try taking it up with your team leader or PM, and if they agree with your case they can probably just make time logging mandatory (that's what's happened where I currently work).

If you're the team lead/PM you need to be more forceful in your role: these people are there to do what you tell them (effectively), and if you need more information to do your job you should get them to provide that information. If they're not willing to help you get the information it's probably because they don't understand why it's useful, try having a talk with them to explain how your projects often go off schedule/get over-estimated/whatever and why it's causing you problems, see if you can turn them around!

share|improve this answer
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.