Are there best practices with time tracking?

Question

What are the best practices for tracking time for developers? Our company has recently demanded that all employees track their time spent working daily with little guidance beyond that other than an application where they can enter their time intervals and what that time interval was spent on?

There's the obvious stuff - meetings, qa, code reviews, development and research.

How do I do this in a way that doesn't punish people for being human at work (needing to run an errand or go to the bathroom, or socializing in the breakroom, etc) and how do I do this in way that doesn't crush the morale of an already productive and well-functioning development team?

Are there any best practices for this?

Answer 1

Are there any best practices for this?

Personally, I know of only three:

1. Figuring out what exactly you want to measure.
2. Accepting a certain degree of measurement error.
3. Trust

You say that your company has recently demanded that all employees track their time spent working daily. Why? For what purpose?

I've been asked to keep track of time on specific categories of work because the company was going for some certifications and that required to have well defined processes, with all sorts of things tracked for auditing purposes, and saying I worked 8 hours today was not enough. I've been asked to track time to map value streams and see where things can be improved. I've been asked to track time simply because it has always been like that. And I've also tracked time for myself to see how much time I spend in unproductive meetings instead of doing meaningful work. Etc.

Then, it's a matter of the measurements themselves. On most parts of the world the work week is 40 hours long, 8 hours per day. So if you need to keep a timesheet for employees, you need to keep if for 8 hours. As already mentioned in another answer, humans can't work for the whole 8 hours. They can be in the office for 8 hours, but can't actually work 8 hours. Humans are not machines. You need to take breaks, you need to stretch, you need to grab a cup of coffee, you need to go to the restroom, you might socialize with people, etc. So where does this time go? Well, on other time tracked activities like development, meetings, research, testing, code reviews, etc., because you can't log your time for half an hour sitting on the toilet trying to rectify your previous decision regarding what you had for lunch.

So whatever measurements you get, you should subtract some percent from that for your employees being humans, not robots.

And the last point is trust. Trust that people are keeping good record of their time, instead of spending the last half an hour of the work day on Friday to try to remember what they did the whole week, and putting all week as development when in fact for half of the time they were in stupid meetings. And trust that whatever reasons the company has to ask people to keep track of time is not simply to punish them or control them in some way (a good indicator of what's going on is if they insists people track their time up to the minute, but every minute people working above 8 hours per day needs to be tracked as exactly 8 hours per day, not more, 'cause that means overtime that by law needs to be paid).

With these three things clear, as David Espina already mentioned, you need to create some common sense rules for how to track things, and make sure the measurements are valid for whatever you are doing.

And finally, remember that people change their behavior when they know they are watched. So if you put a dumb system in place, people will find ways to game the system. And you not only get low morale people and a reduction in productivity, but whatever measurements you do will be completely useless, or worse, present a false image of what's actually going on, and decisions will be made based on that, who will then only make things worse not better.

Answer 2

What are the best practices for tracking time for developers?

Don't do it, unless you can explain why you need it and what you do with the results.

Negative example:

Our company has recently demanded that all employees track their time spent working daily with little guidance beyond that other than an application where they can enter their time intervals and what that time interval was spent on?

Positive example:

I ask all our team members before each sprint, how many days they will be working next sprint. Some may have days off or other bigger commitments in the company that keeps the from working in the team. The very next day, they get a forecast how much "power" our team has this sprint compared to other sprints in the past and they can use this number to see what amount of work they want to tackle.

---

Tracking time is busywork. At some point you will have your team ask where they should track the time they spent on tracking time. No joke, I have seen it.

Answer 3

How do I do this in a way that doesn't punish people for being human at work?

Tracking time implies a lack of trust. This may be more acceptable in some areas than others. Considering the intrinsic motivation of knowledge workers. Distrust clashes with autonomy, which means that you're already punishing knowledge workers by tracking their time. There's no way out.

If tracking time is not optional, consider some basic ground rules:

• Expected worked time should be a (smaller) fraction of contractual time (as David mentioned above). A ballpark used is around 80% (or less)
• Agree in advance if it's expected from people to work only the agreed period (and what happens when this period is under / over utilized)
• A follow up on the previous, make clear rules if over / under utilized time can work on employee's benefit (i.e. one can work 110% of their time in a week and 90% on the week after)
• Whether hours will be approved / reviewed in some sort of tool or not. If so, who'll be involved on this

Answer 4

It is already presumed (or should be) that x hours of time = y hours of actual productivity where y < x. I am using variables because I think that the actual ratio can vary industry by industry and perhaps organization by organization. Therefore, there should not be any punishment for someone taking a break to go eliminate waste because there would be no requirement to record it. There should be rules that, if a break exceeds a certain amount of time, it gets recorded appropriately.

So the best practice is to create rules that represent normal human work behavior.

Answer 5

Trackings Hours Instead of Results is an Agile Anti-Pattern

What are the best practices for tracking time for developers?

Just don't. The agile best practice is generally to measure outcomes, not time or effort expended. While time tracking is a somewhat necessary evil in certain legacy business domains or when tracking time-and-materials, you're generally much better off setting objective goals for deliverables based on the team's ability to reliably deliver at a predictable cadence.

If you have a 10x developer who delivers more work in less time, does it matter if they spent 40 hours delivering it or only four? Unless you're paying that person 10x the salary of the rest of the team, paying by the keystroke, by lines of code, or even time at the desk is often a pretty whiffy anti-pattern in most agile shops. Those approaches generally result in more visible effort and less actual work done, so make sure you're measuring what the client (or the company) really wants to pay for.

A Better Approach

In most agile engagements, teams have an average run-rate per iteration. As long as your team is meeting its goals more often than not (I personally strive for around 80% of the time on projects I oversee), then your best bet is to identify the optimum sustainable range of productivity for the team. You can then make decisions about team or individual productivity based on statistically significant deltas from that consistent cadence.

Answer 6

You need to know what the exact requirement is, go back and ask.

Many companies are required to track employee working times for legal reasons. That means they don't care what the employee is doing, they want to know when he started work and when he finished work. For these cases, you need a modern equivalent of the old punch clock.

Now if you want to track productivity or use time tracking for project management, simply use the time tracking feature of your issue tracker. JIRA, for example, lets devs record time spent on an issue simply by entering "30m" or "2h". That's extremely easy and adds minimal overhead. Comments are optional.

I can tell you one thing from 25 years of work experience: If the time tracking is a hassle or feels like surveilance, people will circumvent it and start lying. Make it easy, automate it as much as possible, track the absolute minimum.

Answer 7

Let's always keep this famous quote in our minds; If you can't measure it, you can't improve it.

I always hear that the developers should work whenever they feel it's the right time, and the managers should not keep track of their time.

Developers are not artists; they don't need any inspiration to start coding. They have specific tasks to complete within a reasonable timeframe according to estimations. So, the "productive hours" terminology should not be treated as the actual working hours left after many non-work related stuff people do in their work week, like shopping, reading news, socializing.

The "productive hours" means the time allocated for work directly related to the company's goals and what an employee is mainly paid for, like coding a project or having a sales meeting with the customer. The "non-productive hours" is the "work-related others" like HR-related paperwork, weekly happy hours, training, exams to take, company events. Personal needs, watercooler talks, etc., should not be counted in your workweek because they are not work-related.

Let's say, by regulations, a working day is being at work between 9:00 AM and 06:00 PM, which makes 9 hours a day; that's "the duration hours" of a workday. If you define "1 hour a day" to be spent on lunch, personal needs, socializing in the company, etc., then 40 hours is "the work hours" of a workday. You can provide a percentage for the productive hours of your work hours. Suppose your "productive hours percentage" is 90%. In that case, you should expect 36 hours to be spent on the direct work. Any time allocated for meetings, code reviews, development, and research should be counted under the "productive hours", and they should be directly related to a project, initiative, task, or whatever your work unit is.

When you communicate this well within the company, you will get meaningful timesheets to work on and understand where your developers' most productive or non-productive hours are spent.