Time tracking exercise and what problems it solved

Over the years I have migrated between the role of a Product Owner towards a Scrum Master. While those may seem like heaven and earth (depending on where you’re seated at the time) one problem was common and equally frustrating i.e. sprint planning vs actual delivery. I’ve worked with a countless number of teams I would using anything from time to points estimation but regardless of the technique, the problem of not delivering of the agreed scope was always there.

There’s been a project where we have decided to start using story points: the team was working on it for over a 6 months at that point and they were happy and open to make a change. After 5 sprints I had a solid idea what the velocity of the team was.

All of the sudden some strange things started to happen. Velocity was shrinking — each sprint we delivered less and less points, and even if I took fewer points into a sprint, tickets were still not getting completed. I have quickly realised that there are some external factors that I’m not aware of that are impacting my team and slowing the work. Not to mention the client that was not exactly happy 🙁

So I have decided to introduce Toggl in 2 teams in parallel to test:

What is time spent on — time not covered by a Sprint tickets,
The accuracy of the estimations,
How is estimation affected by a senior developer. Even though we used poker planning software when everyone had to vote before the score was revealed, it was clear that the less senior members were estimating under the influence of senior member. They tend to not see all possible problems or were over-optimistic in their estimations.

I have of course explained the reasons for the time tracking exercise to the team. That I’m going to treat it as an exercise, that I would track my time too etc. I have explained we need to quickly pinpoint where the biggest challenges with the project are, how we are falling behind the scope and that I want to understand how the recently introduced code review rules seemed to hugely increase time that is being spent on the ticket.

At first, the team wasn’t happy about time tracking. The reasons can be easily guessed:

It’s time-consuming,
I’m forgetting to switch the tracker when I start new task,
When I’m doing code review I’m quickly switching between the tasks so it’s pain to change also tracker every time.

There are also reasons that were not being expressed out loud but are common to human nature:

Someone wants to control me,
I’m being micro-managed,
The management want to check on me,
They don’t believe I’m working my hours (especially remote workers),
I do my tasks longer then I admit, now I will have to show it — I’m afraid of the results / consequences,
Am I not that good programer as John, he does his tasks faster…

One of the great benefits of time tracking is the understanding of where and how your time is spent. Once you start tracking your time you can see the big picture and how productive you are. By productive I don’t mean how quickly you work of course.

Speed of delivery doesn’t equal the quality of the code produced. I much prefer to work with developer whose tasks are properly done with time spent on understanding of the ticket scope, that doesn’t require a lot of changes during the code review and pass QA, rather than a developer who quickly does his task, then needs to fix it several times during code review and at the end QA rejects this ticket as it’s not fully completed.

I went slightly off topic here, so let me get back to my teams…

Very quickly I have realised that in team A the problem was with work that was done outside tickets. The biggest offenders were:

Client would ask for calls to discuss technical requirements for the new features or solutions. And those were not 5 min calls. As we started to measure those calls I was able to add placeholders for next sprint to cater time spent on new features discussions. I was also able to present to the client how it impacts speed of work.
There was some maintenance work required for deploys, problems with the server, changes to code review / deployment process etc. They were important but not communicated clearly so done outside sprint scope. Also if you measure it, you can be better prepared in the future and allocate the time needed to complete these.

At the same time, team B has just started to work on new project and was using time estimation. After the first time-tracked sprint, I realised tickets were underestimated by an average of 64% (!). When the time for new sprint planning came, I have pulled my report and explained the results to the guys. They were surprised but really interested. You can probably guess that the next sprint was much better estimated 🙂

How time tracking helped me to manage my team better:

Having collected the data I could see the bigger picture and introduce small, iterative adjustments. I could see the breakdown of weekly time blocks like calls, tasks, code review, and other not sprint related tasks. Here are some of the main points:

Time on calls is significantly longer for remote teams
Time breakdown will be different for each role in the team (developer / tester / SM / PO)
Newly introduced rules for code review were too strict and slowing down work
Team tried to generate “best code” and to cater for all future possible scenarios instead of focus on the ticket scope
Some of the team members had their tickets stuck in code review for a longer time as the code was not properly written. Also, some team members took longer to code review. Knowing that we could help them to improve areas that needed it most.
During daily planning, it was soo much easier to talk about yesterday work when you had list of the tasks from toggl in front of you.

How time tracking helped me to manage my time better:

I never had problem what to do at work, I wouldn’t sit during work hours staring at the computer screen wondering what to do – there was always something that urgently needed to be done. The problem was that when working on multiple projects where I was billed to the clien a on % basis, I was sometimes confused how much time I spent on what project and if that was fair to the customer. Also the question was if I was not spending too much time on the project. When you overdeliver, the customer assumes it’s still the standard 25% week time and would not understand the reason of increasing my role permanently to fulfil all tasks.

Time tracking software

There are several time tracking tools on the market. I personally have used Toggl and Harvest but you should have a play around to investigate before you decide.

Here’s a list of other time tracking tools you should consider:

And what about you? Have you tried to implement time tracking within your Agile workflow? Please share in the comment below or feel free drop me a line 🙂

Need our help?

Let us know more about your needs.