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.

  • 7
    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 Commented Jun 3, 2011 at 20:47
  • 4
    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
    Commented Jul 27, 2012 at 16:31
  • 2
    Where do I put the numbers for the time when I solve a problem on the way home?
    – Pieter B
    Commented Oct 25, 2013 at 12:25
  • 1
    @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. Commented Oct 25, 2013 at 12:59
  • 1
    @PieterB Definitely a gray area. All depends on whether it's useful to track when making schedules and project estimates. Commented Oct 25, 2013 at 16:25

14 Answers 14


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.

  • 2
    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
    Commented Jun 3, 2011 at 13:40
  • 4
    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
    Commented Jun 3, 2011 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. Commented Jan 15, 2013 at 20:57

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.
  • 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. Commented Jun 3, 2011 at 13:41

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

  • 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
    Commented Jun 3, 2011 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." Commented Jun 3, 2011 at 18:19
  • @Wonko +1 for "estimation dice" :-)
    – sdg
    Commented Jun 3, 2011 at 18:22

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.


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.

  • 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
    Commented Jun 3, 2011 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
    Commented Jun 3, 2011 at 18:20

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!


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.

  • 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
    Commented Jun 3, 2011 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
    Commented Jun 3, 2011 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
    Commented Jun 3, 2011 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
    Commented Jun 3, 2011 at 18:28
  • Unfortunately I'm not in a position to mandate any time tracking, so I need to find alternative methods. Commented Jun 3, 2011 at 18:44

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.

  • +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
    Commented Jun 3, 2011 at 22:57

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?


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.


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.


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..


Instead of convincing them to enter their numbers, use a software that works effortlessly. I'm using ScreenAware: https://www.screenaware.com/en/ It tracks your time automatically and assigns it to the respective projects. So it's always accurate and no one has to guess anymore

  • This specific solution may not work for OP's general question. While it's fine to provide links, next time try to provide a more general solution unless OP specifically mentions requesting software solutions for his problem.
    – Neil
    Commented Jun 27, 2017 at 12:42

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.

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