My company recently introduced time sheet logging for each individual in the development team. To be honest, it is quite time consuming. Each member needs to log what they have done each day.

They mentioned that the purpose of this is to provided a history of a project plan for later reference, but sometimes they will say "Let's check what you have done recently." It feels like we are not being trusted.

  • Related question on another Stack Exchange site: As a programmer, are you required to do timesheets? Oct 6 '15 at 6:59
  • 1
  • 1
    Are you using a particular project management methodology (e.g. Scrum)? And are you part of an agency or other business that has clients? In the latter case I think timesheets are pretty common so you have a paper trail for billing purposes.
    – Willl
    Oct 6 '15 at 12:32
  • 1
    I would fill it out to the extent that my time on projects was trackable (and billable), but not to the level of detail to allow poor quality managers to try to use it as a reductionaist metric to assess performance. Typically I put "8 hours, Foo project, Dev". Assesing velocity should be done elsewhere as a whole team activity. Oct 6 '15 at 14:18
  • 1
    If filling out the timesheet takes a considerable amount of time and you want to be honest, be sure to add an item to the sheet for filling it out. Oct 7 '15 at 17:37


In general, logging is a symptom of a non-agile development process that proxies for a project manager's active engagement and situational awareness. It is also often a sign that the project is measuring the wrong thing, since "time consumed" is rarely a valid measure or predictor of results. When not used solely for contractual billing purposes, it is most often improperly-used as an accountability or root-cause analysis tool.

Results-based tracking is generally more effective. For example, in Scrum a story is either "done" or "not done" at the end of a Sprint. How much time was spent doing what task inside the Sprint is largely irrelevant, although blockers and queuing issues are certainly valid topics for a Sprint Retrospective.

The Fallacy of Detailed Time Accounting

Tracking time is useful for billing purposes, and ostensibly for future estimates. In reality, though, time sheets are either a work of fiction or needless overhead.

In manufacturing, it can certainly be worthwhile to document that it takes x minutes to produce y widgets on an assembly line. However, in knowledge work like programming, work rarely breaks down neatly into measurable increments. In addition, programming in particular is often about thinking about the right problem to solve, so overly-granular record keeping that isn't a complete work of fiction might look like:

  • Spent 47 minutes thinking about how to optimize the frobnitz.
  • Spent 52 minutes writing a spec for an experimental wibble widget.
  • Spent 12 minutes coding a new quux object.
  • Spent 17 minutes deleting a bunch of code objects, documentation, and references that should be torn out in favor of the quux object.
  • Spent 21 minutes waiting for continuous integration to run.
  • Spent 3 minutes every quarter hour summarizing the work, and 23 minutes and 15 seconds getting back on track after interrupting my work to log my time.

If the log is kept meticulously and honestly, at the end of the day the time simply won't add up to 8 hours due to task switching, overhead, and (of course) the time spent time-tracking at a granular level. That makes the log less useful than managers might like to think.

Sensible time-keeping tends to be less granular. A sane log entry might say: "I spent 6 hours today working on the foo project, and 2 hours in meetings, time-keeping, and other project overhead." However, this type of high-level logging is often imperfect due to cognitive bias, errors of omission, social filtering, and other factors that make it largely useless as a valid measurement.

Results-Based Project Management

Agile frameworks like Scrum implicitly support a results-only work environment. While ROWE itself is a buzzword and marketing term, the concept of measuring results (e.g. Was a target met or not?) is generally more useful than measuring minutes-per-task. Again, sectors like manufacturing that need to measure throughput may actually need timing data, but rarely do they need timing data of the sort collected by the time sheets you're describing.

Focusing on whether tasks are "done" or "not done" is a significant culture shift in many organizations. It requires trust between upper management and the development team, and a commitment by the team to be transparent about estimates, impediments, and missed targets. Without that trust, and without that culture shift, most organizations simply fall back on useless metrics like time accounting.

If your organization isn't willing to make that cultural shift, and if you find granular logging disruptive or burdensome, then you can try to evangelize a more agile approach. More likely, though, it's simply time to brush up your resume and look for an organization that is less steeped in failure.

  • 1
    Cannot agree with you here. You wouldn't track time at the detail level that you indicated here. You track it at the work package level where you loaded your hours for the plan. You would not have a work package that calls for "deleting a bunch of code objects...." Oct 6 '15 at 18:09
  • 1
    @DavidEspina The OP says "[T]hey will say 'Let's check what you have done recently.' It feels like we are not being trusted." Nothing in the original post talks about work-package loading or matching granularity to a WBS, which I address in my 2nd section as "sensible time-keeping." The OP is clearly being asked for a detailed account of time spent, ostensibly for the purpose of "holding people accountable" for productivity or time management. I've worked at companies that do indeed ask for this level of detail, and that "wish away" tasks like refactoring. It's not as far-fetched as you think.
    – Todd A. Jacobs
    Oct 7 '15 at 0:15

I have worked in organizations that track time to 15 minute increments and those that don't track time at all.

From a PM perspective I greatly prefer the former, because it is next to impossible to objectively estimate future effort if you don't have history of actual time spent. In my current organization we have to go through all sorts of contortions to figure out how many projects can be implemented, how these are to be prioritized, etc etc. It would be much easier to start a conversation on project prioritization if we could go to our leadership and say "We have XX warm bodies, in our experience we can successfully execute YY projects with that level of staff".


I second David's thoughts on this one. I had to do time logging for 8 years - first down to half an hour then to an hour - and the only time when it was "painful" when I helped somebody else on a matter I had nothing to do with, therefore I was unable to log any hours there.

From the project's perspective it has some benefits, because the team/PM will know how much effort has been put into the project, and see whether they are still on the budget or not.

This can be also a helpful data for leads to see who are involved in many things and help to reduce the pain context switching causes.

Team mates argued a lot that it took them too much time fill out, and when we actually measured it was about 10 minutes on a Friday to do for the whole week. The second argument was about trust as you've already mentioned. I have met only one PM that used the time sheets for figuring out what the people were doing - instead of going there and see by herself -, others tried to fix problems. There weren't that interested in the details either. Engineers spent a lot of time on filling the sheets out very precisely, which they were never asked to do. The PM was interested in the rough numbers just to see where the project is.


Like others here, I had to track my time to the 1/4 hour level for years as a consultant. I hated it at first but learned to embrace the effort because of the information it provides down the road. Don't neglect the comments!


As as developer I have to say I agree that this can be a pain in the arse. It's fine if you are assigned to a single project, or the chunks are large, say a day on this a day on that.

The problem occurs when you have to work on multiple random things in a single day and they just don't fit into the nice ordered time keeping system that's been set-up.

Say for example I'm on a BAU team, implementing features from a scrum board. I have my task for the day and I can assign time to it no prob. so I'm working away and manager Bob comes up to ask me about a possible bug a user has reported. Its probably nothing but can I investigate? Then developer Jim wants to ask me about some code I programmed last week, Sales Jane ask, can I goto a meeting to discuss the interface for new customer Z? HR Sam can't upload his spreadsheet to internal tool Y, can I run off a quick report on something from the database? etc etc

"But!" you say, we are doing scrum/kanban/agile of the week! you should say "No!" to all these things and and the Scrum master to intervene writing up tasks and prioritising them!

Unfortunately the practical effect of this is forces developers to choose between being 'scrum police', working overtime, having hours which don't add up on the system or 'rounding up' those hours.

Additionally business tend to rely on this "Shadow IT" pushing devs into being 'unit of work style, only do tasks on the board' machines puts a huge pressure on project managers and BAs to correctly spec those tasks, leading to a waterfall style approach. exactly the opposite of what the business wanted.


I would venture to say that those who think they're not being trusted likely have something to hide.

Collecting data on a daily basis is important in both measuring performance against your cost and schedule baselines as well as inputs into future projects that are similar. It is done daily in order to increase accuracy and precision because, if done weekly, then most likely the data is a best guess, which makes the data useless. Workers should capture as accurately and precisely as possible the hours worked against a particular work package.

We all capture our time, from laborers who clock in to professionals who log hours to bill their clients.

It is absolutely necessary to manage projects and business. If this offends you, take a long hard look at what you might be hiding from your boss.

  • I'd disagree that collecting time data on a daily basis is a means of measuring performance against cost. Time spent in software development does not equal performance. There may often be a correlation, but there is no causation that more time spent equals increased performance. Measuring performance or productivity of workers in knowledge-based industries is incredibly hard and arguably more costly than the value provided by capturing it in a timely and accurate metric.
    – WBW
    Oct 6 '15 at 19:08
  • I did not write that more time equals increased performance. This reaction to my answer is surprising. This is what projects are about. We plan projects in scope, cost, and time. We use planning values to budget how much we are going to spend and how long it will take. If you do not capture actual time, which is a necessary input for cost and schedule, then how can you know where you are against both cost and schedule? How can you forecast where you will end up? It is a required input. Oct 6 '15 at 19:15
  • And, yes, it is a difficult task and subject to less than accurate data coming in. So what? You still have to do it and figure out ways to make the data more accurate. This is basic PM stuff. Am shocked at the down votes. Oct 6 '15 at 19:16
  • 1
    Didn't realize the question was posed to be answered strictly using the traditional PM lens of scope, budget, time. Down vote was actually because the original answer implies the question poser has something to hide and offers nothing to address the problem of perceived trust issues between those asking for the time metrics and those providing it. There are many ways to manage projects and business, a number of which don't rely on time tracking or assuming you are hiding things from your "boss."
    – WBW
    Oct 6 '15 at 20:15
  • 1
    Answers here are NOT about traditional PM. If an answer is provided that is traditional PM, it does not make it wrong because there are other methods and approaches. I offered sound reasons, substantiated reasons, why this data is collected and opened the door to the possibility of something to hide if one is perceiving being micro managed or not being trusted. Oct 6 '15 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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