Six Reasons for Time Tracking in Agile Projects

Tuesday, June 25, 2013 by Rainer Stropek

Time tracking in agile projects is a controversially discussed topic in many project teams. Some people – typically the developers – argue that time tracking is at least unnecessary if not unwanted when following agile principles. They refer to documents like the Scrum Guide which says that “Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest”. On the opposite side of the spectrum there are people – typically managers – who insist on detailed time tracking. They work according to the famous saying “you can’t manage what you can’t measure”. Agile is fresh, it is new. Therefore asking for time tracking might seem old-fashioned and somehow related to the often criticized waterfall model. However, there are a lot of valid reasons why you might still need time tracking even if you decide to work the agile way. Let’s take a look at six of the most important reasons.

1. Time Tracking is the Basis for Billing in Time and Material Projects

Big design upfront methods typically fail dramatically for project which can be found in the Complex or Anarchy area on Stacey’s Agreement and Certainty Matrix (see figure below). Agile project frameworks like Scrum shine for such projects because they have been designed for constant changes of requirements and/or underlying technologies.

Stacey's Agreement and Certainty Matrix

As a result the agile approach is often used for projects in which requirements are not very well known at the beginning. If you have an external customer for such a project, you will likely offer charging based on actual person-hours. A fixed price would not make sense because of the high level of uncertainty. In such projects time tracking will be the basis for your billing process. Data quality in time tracking will directly influence your revenue as every forgotten hour means a loss of money.

2. Enhance Your Ability to Accurately Estimate by Learning from the Past

Countless studies have proven that experts tend to be over-confident. If you ask them for a range estimation with a 90% confidence interval (chance of containing the correct answer), you will in fact get a much lower confidence interval. In his excellent book Software Estimation – Demystifying the Black Art Steve McConnel measured a confidence interval of 30% when doing an estimation quiz with hundreds of attendees (see also following figure 2.1 from this book).

Software Estimation Confidence Interval

Enhancing the ability of a team to estimate effort more accurately is difficult. Having a time tracking database with estimations and related actual working-times is a possibility for systematic estimation trainings. Studies confirm this by suggesting “that software companies provide estimation training opportunities through their database of completed projects” (Jorgensen, 2002).

3. Time Tracking Might Simply be a Legal Obligation

If you like it or not, in many countries tracking employees’ working times is required by law. In such cases it is typically only necessary to track people’s attendance. You do not have to track the content of work. However, the step from tracking attendance to tracking the work spent for certain projects or tasks is not far. The other points in this list might convince you that accepting this extra effort is worthwhile.

4. Use Time Tracking to Keep Track of Your Project’s Budget

Real-time projects have limited budgets. In the real world projects need mid- and long-term road maps. In reality available budgets influence product planning. As a consequence, real-world projects needs a certain degree of up-front costing and constant monitoring of projects’ budgets.

Keeping track of a project’s budget is rather simple in an idealistic Scrum project as the entire project team is dedicated solely to a single project. It starts getting tricky if you have people (often product owners or Scrum masters) contributing to multiple projects or if you have sub-project-level budgets (e.g. because a certain stakeholder has to pay for a certain product backlog item). In such cases your time tracking database will be the basis for calculating remaining project or story budgets.

5. Allocate Costs of Team Consultants Based on Time Tracking Data

Scrum emphasize the importance of self-organizing and cross-functional teams. Each team should have all the competencies needed to do their job. However, in real-world projects Scrum teams sometimes need the help of domain experts in order to fill a skill gap between the team and the project. In his informative book The Scrum Field Guide, Mitch Lacey added the following table elaborating on differences between core Scrum team members and team consultants:

Differences between team consultants and core team members in scrum

Team consultants provide shared services as they work for different projects. In order to allocate costs correctly you will need information about their time spent for each project. Without this you have to change e.g. equal costs to all internal customers. This would inevitably lead to conflicts about project costs and budgets.

6. Manage Cross-Team Efforts and Administrative Overhead

Agile in general and Scrum in particular foster self-organizing, autonomous teams. However, in larger organizations there will be a need for cross-team efforts. Here are some examples:

  • Do you remember the agile principle “customer collaboration over contract negotiation”? Well, in large organizations with many agile teams, contract negotiation is still important. How else should you manage cross-team dependencies?
  • The agile manifesto values responding to change over following a plan. However, in practice it will be necessary to spend some time for planning e.g. the architecture of the software product you are going to build. Eric Brechner puts it in his book Hard Code like this: Agile does not mean “to jump off a cliff and see what happens next”. Agile means that you should be willing to change your plans in response to changed requirements.
  • Your sales team will be asked by customers about release plans and roadmaps. Project frameworks like Scrum have strategies for creating such plans based on you teams’ velocities, story points, sprint lengths, etc. Someone will have to spend some time creating and documenting the plans and keeping them up to date.

How Time Cockpit Can Help

Time cockpit is the leading time tracking solution for knowledge workers. Graphical time tracking calendar, automatic tracking of your work using signal trackers, high level of extensibility and customizability, full support to work offline, and SaaS deployment model make it the optimal choice especially in the software development and IT consulting business.

Time cockpit contains a powerful API and scripting language. You can easily integrate time cockpit with your agile project management tool. Sample implementation for interfaces to MS TFS/TFService and Jira come out of the box.

comments powered by Disqus

Rainer Stropek

Rainer Stropek

Co-founder, architect, developer

Bio

I am co-founder and CEO of the company software architects and have been serving this role since 2008. At software architects my team and I are developing the award-winning SaaS solution time cockpit. Previously, I founded and led IT consulting firms that worked in the area of developing software solutions based on the Microsoft technology stack.

In my work I focus on .NET development and software architecture. I have written some books and articles on C#, database development, Windows Azure, Windows 8 development, WPF, and Silverlight. Regularly I speak at conferences, do workshops and conduct trainings in Europe and the US. Since 2010 I have been MVP for Windows Azure.

I graduated the Higher Technical School Leonding (AT) for MIS with honors and hold a BSc (Hons) Computer Studies of the University of Derby (UK).

Contact

Twitter: @rstropek
Facebook
Google+
Xing
LinkedIn

Authors