Time Tracking and Agile Software Development


One of the key aspects of a disciplined agile approach is to be enterprise aware.   The fundamental observation is that your team is only one of many in your organization, except in the case of very small organizations, and as a result should act accordingly.  This means that what your team does should reflect your organization’s overall business and technical roadmaps, that you should strive to leverage as much of the existing infrastructure as possible, that you should try to enhance the existing infrastructure, and that you should work with other teams appropriately so that your overall efforts are complimentary to one another.  This is a straightforward idea conceptually, but in practice acting in an enterprise aware manner can prove more difficult than one would initially think.

Over the years we’ve been asked by several customer organizations to help them to understand how to account for the expense of agile software development.   In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations.   The details of accounting rules vary between countries, but the fundamentals are common.  For public companies capital expenses (CapEx) are preferable because they can boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year).  On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization’s taxes for that year.   Furthermore, in some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature.  In order to get properly account for the expenses incurred by software development teams, and potentially to earn R&D tax credits, you need to keep track of the amount of work performed and the type of work performed to develop a given solution.  Time tracking doesn’t have to be complex: at one customer developers spend less than five minutes a week capturing such information.  The point is that the way that a software developer’s work is accounted for can have a non-trivial impact upon your organization’s financial position.  This in turn implies that the need for agile developers to their track time is a fairly simple example of acting in an enterprise aware manner.

So, I thought I’d run a simple test.  On LinkedIn’s Agile and Lean Software Development group I ran a simple poll to see what people thought about time tracking.  It provided five options to choose from:

  • Yes, this is a valuable activity (33% of responses)
  • Yes, this is a waste of time (39% of responses)
  • No, but we’re thinking about doing so (2% of responses)
  • No, we’ve never considered this (18% of responses)
  • I don’t understand what you’re asking  (5% of responses, one of which was mine so that I could test the poll)

The poll results reveal that we have a long way to go when it comes to working in an enterprise aware manner.  Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity.  When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars.  Looking at it from a dollar per minute point of view, it could be the highest value activity many developers perform that week.

The discussion that ensued regarding the poll was truly interesting.  Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking.  Some comments that stood out for me included:

  • It’s a colossal waste of time unless you’re billing a customer by the hour.
  • We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
  • I think the *most* pointless example was where the managers told us what we should be putting in.
  • One day we will move past the “just do it” mentality and have some meaningful conversations and the reasons for what we do.
  • In my experience time tracking is a massive waste of time. It’s a poor substitute for management.
  • Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
  • Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports.  And they do not believe that Management can resist the temptation to use task hours as a measure.

So what can we make of this?  First, it’s clear that delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they’re doing.  Second, it’s also clear that management needs to communicate more effectively regarding why they’re asking people to track their time.  To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they’re asking for.  Third, management needs to govern more effectively.  Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result).  Fourth, some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and coordination meetings may be preventing people from become enterprise aware because they believe that all of their management needs are being met by these practices.  Finally, many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.

In Summary

Disciplined agilists are enterprise aware.  This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization.  In the anecdote I provided it was clear that some agile developers believe that an activity such as time tracking is a waste, when that clearly doesn’t have to be the case.  Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization.  It makes me wonder if some of the agile rhetoric is getting in our way of being more effective as professionals.

5 thoughts on “Time Tracking and Agile Software Development

  1. Gustavo Narea

    Thanks for this interesting article, Scott. It’d be great to see a follow-up on how to use the data.

    We use JIRA and Worklog Assistant to track time, and it really couldn’t be quicker/simpler if you have both properly configured. I am personally very precise with my tracking (i.e., I pause it on every break) and I’m sure I spend less than a minute a day just doing this.

    In my experience, developers are more willing to track time, compared to designers. Which I find ironic because lots of agencies and freelancers charge by the hour.

  2. Raphael Branger

    Thanks Scott for this article! As a consulting company we do charge our customers by hour, hence time tracking is crucial. But I see yet another important aspect of time tracking in agile: working in an agile manner in a “consultancy-customer” relationship is based on a lot of trust on both sides, Even more trust is needed if not all the work can be done onsite at the customer. One mean to foster trust here is to provide time tracking data to the customer. In addition, our consultants have a possibility to report their hours and specify themselves what they think what we can really charge to the customer. For example if we need to learn a new tool and do some experiments with it during a regular iteration we provide high transparency to our customers by showing them what activities are charged but as well what we invest on our side (and free of charge for the customer) to make the project a success.

  3. Renaud

    Time tracking should not be for the sole purpose of accounting. Historically, it has been justified this way and this is why it failed in many organisations.

    Time tracking can benefit to the teams. It provides clear feedback about the accuracy of the estimates and gives clues about how to improve them in the future. It provides facts and data for the Sprint review about what went wrong. And it costs only 5 minutes per week.

    Thanks for the article (especially for the reminder about CapEx and OpEx). A must read for Agile teams.

  4. Rick

    Thanks for this article. I just switched form a waterfall org to an agile org, and have been tasked with drafting up some Progress and “Actuals to Estimates” reports. Except the Agile org doesn’t track time at all. I probably won’t be able to change that, as the new guy, but this article at least has some good insights to share in the team meetings!

    1. Scott Ambler Post author

      Rick, glad to hear that the article has some good ideas for you.

      The fundamental issue to consider is whether time tracking, and how much, adds value to your organization. Very often the team itself isn’t a good judge of that, and the agile knee-jerk reaction is often “that’s needless bureaucracy”. However, more disciplined teams that are enterprise aware often realize that there can in fact be some significant value in doing so.


Leave a Reply

Your email address will not be published. Required fields are marked *