Clearly from those that have to do it or manage it, the answer is a resounding yes.
Is it that clear-cut? Of course not. So let's delve into it, by firstly asking why firms want it.
There are a few reasons to want staff time tracking, we’re going to focus on delivery teams but fundamentally the issues are the same:
1. A lack of trust - Management wants a good idea of who’s doing what and is time being spent effectively. Are people doing what they should be?
To be honest if this is the main reason it's needed, then there will be far larger problems with staff empowerment and retention. Asking the staff to record how their time is allocated is easily fudged and doesn’t really solve this problem. I would also argue that a management team that views this as a useful investment of time and effort has fundamentally misunderstood intrinsic motivation and the accuracy of the easily gamed data that they collect. Ensuring alignment between leadership and staff on the organisational goals and how the work drives that gives a far better focus on doing the right thing and decent line management deals with performance problems far better than timesheeting ever would.
If you’re doing timesheeting for this reason then please stop and seek help. Agilicist be more than happy to assist!
2. Allocation of spending - This is a far more likely reason for needing timesheeting. It can be divided into a couple of broad categories and sometimes it's just one or both of these that are the reason it’s required:
A. Internal or external project charging - Be it cross organisation or customer charging, we have a group of staff working on something specific that needs to be charged to someone. If they are working on multiple things or have mixed development and operational responsibilities then it starts getting messier and why timesheeting exists is understandable, but also avoidable.
B. Accounting reasons - The need to allocate capex/opex for things like capitalisation can drive the desire to know exactly what people are doing and then deem certain tasks/activity to be one or the other.
The problem with relying on timesheeting for allocation of charges or accounting is that it's not accurate. The staff are often guessing or answering quickly with minimal effort/thought. Across all the staff required to do it, it's a huge amount of effort to capture what is effectively guesswork. This guesswork is then bizarrely used far more scientifically than it deserves to be and it is very poor quality data for the effort expended.
‘So what?’ I hear you ask, surely when it is aggregated upwards then it is better than nothing or good enough? The problem here is that I would argue that it could be calculated automatically and more effectively, without wasting time with a timesheet process/system.
Crudely put, it's as simple as classifying work at a higher level: initiatives, epics, features, as certain types or for certain customers. Work the team completed can then be calculated by the capacity of the team, and then apportioning financials to all the team work items over a time period divided by the relative size of each item.
Why does it need to go down to an individual person? In fact I would say it's worse to track at the individual level as inaccuracies at the micro level, when aggregated, lead to far greater inconsistencies at the macro level.
For opex and capex, the work is easily definable by what it is, and classified opex or capex. Typically much of the work done by development teams is capex. This can be further simplified if certain roles only engage in one type or another. If the team has operational and development duties then calculate an overarching percentage of time spent (say 20% on live issues/maintenance etc..) rather than micro-gather guesstimates.
OPEX (Product Pipeline) | CAPEX/OPEX | OPEX |
Product Strategy, Plans, Epics, Features | Teams (and POs) delivering Stories (Dev/Test/Deploy) | Maintenance, live bug fixes, refactoring etc.. |
Also I would caution against trying to attribute financials to the story level as not only does it not help or give greater accuracy, but Increased Granularity = Increased Overhead & Reduced Delivery Velocity. (Doing it at story point level is even worse as SPs should be relative and flexible, monetising SPs ties them into time and drives some very unhelpful behaviours, but we’ll cover this in another article at some point.)
If the need is project allocation specific and teams are not ring fenced for that work only, then again, track it as whole features or epics that teams deliver and attribute those to wherever applicable time and charge accordingly.
To get this working as easily as possible, then in reality you’ll need to leverage workflow tooling to help (Jira, AzureDevops etc..) and a portfolio view like BigAgile. Clearly teams also keep their data accurate and up to date but they should be doing this anyway, as they go along. So use that data, in better ways, and remove the additional overhead of the laboriously misleading timesheeting approach.
It is time to question the benefit and veracity of timesheeting. It wastes time, it's not accurate and it's an annoying overhead that can be far more simply calculated from existing workflow data instead.