Measuring Developer Utilisation Without Timesheets

Ah timesheets. The daily, weekly or, if I’ve forgotten long enough, monthly charade of accounting for how I’ve spent my days has done more than anything else to earn me the soubriquet of Captain Grumpy over the years. There is just so much wrong with the ways time recording has been done in my career. Some examples:

• “We only have 1 time entry, just record 7.5 hours against it for each day you are here”. OK, this is easy, but why can’t I just record when I’m not here.
• “What do I log this 4 hour meeting against?” Organiser of meeting: “Oh, there isn’t an entry, just find something you think looks acceptable.”
• I once implemented time tracking at a dev task level using Jira. The company then decided to use reports out of Jira to bill our customers. Good idea! But then we ended up having to create Jira tasks for our sick days, annual leave, public holidays, etc.

That last one is a particularly pertinent example. I was trying at the time to improve the team’s collective ability to estimate by tracking estimated effort versus actual in Jira. As soon as it was used for billing purposes any hopes I had on that front were dashed. No longer could I measure the actual time spent on a task. The first objective was to make sure exactly 7.5 hours (not a minute more nor less) was logged each day on billable tasks.

Fast forward to today and I am busy trying to cultivate a culture that is focussed on output rather than input. Therefore it seemed a reasonable assumption that we wouldn’t measure utilisation at all. After all, Agile principles tell us that we want to measure the overall features delivered by a team and we can use story points for that. And Agile principles also suggest that our team will work on one product/project and not multitask. But sadly for me at the moment we aren’t at the stage where we can assign a complete team to a project. The best we can do is try and minimise the multitasking each individual developer has to do.

So we are left with a situation where I try and broadly plan the allocation of each developer each week. Our team needs to know the allocations before they agree to the amount of features to be developed in a sprint. It is then beneficial to track the actual allocation that we end up with to help me adjust future plans.

So timesheets then? Well, not quite.
I’ve written previously about how much I love the Pomodoro technique and the boost it has given my personal productivity. Our entire development team has subsequently adopted the technique.
Now, most of the Pomodoro tools that are out there work on the idea that you can assign a task to your Pomodoro. Then at the end of the day or the week you can get some simple reports about how many Pomodoros you spent on each task.
And that’s all I need to know to track utilisation of each developer. Everyone can work with their preferred Pomodoro length since I’m only interested in knowing that Andre spent 80% of his time on Project A and 20% on Project B and that Ruth spent 50% on Project B and 50% on Project C. Collating all this information is very straightforward and at the moment is done in a spreadsheet although I crave something more automated.
So there you have it. The bean counter in me gets to measure some metrics I consider important without imposing any additional workload on the team. All is good provided the team sees the benefits of the Pomodoro technique (and why wouldn’t they?)