If it is true that time is money and, once lost, can never be found again, it should be no surprise that the “work smarter, not harder” mantra has become the drumbeat that agile developers must march to. One pillar of project estimation is having a solid grasp of how long will a given task take, and how long to complete the entire project.
Even for those who have a strong grasp of this concept, delivering truly accurate estimates can become a frustrating, time-consuming process that results in projections that are far off the mark. Why? Because falling prey to the wiles of the “time trap” is easy, even for the most seasoned professionals.
Conventional wisdom dictates that tracking time against estimated tasks enables more precise comparisons between actual and planned estimates. In theory, this should allow for greater accuracy and better estimation practices.
However, the truth is that more often than not, time tracking becomes a trap—a perilous sinkhole masked by a seductive façade—that sucks in developers, project managers, and whole teams. One of the greatest dangers posed by the time trap is inaccurate estimates that result in hazardous outcomes, including overruns and a drop in the perceived value of the project (and by extension, individual developers and the team at large).
Some people can become bogged down in the minutiae of accounting for every minute spent on tasks or projects. The relentless drive to capture more and more data can become a serious obstacle, a bottleneck leeching away productivity that prevents project stakeholders from completing critical work at hand. Too often, it seems that time tracking can devolve into an intrusive burden, imparting the feeling that Big Brother is peering over people’s shoulders.
With so many diverse tasks needing attention throughout the workday, accurately tracking and recording time spent on each individual item is inherently troublesome. So, while most developers try to honestly account for their day, trying to make the numbers add up to a full eight-hour day can result in unintentionally fuzzy time-keeping, ensuring that future estimates based on this data are inherently inaccurate.
Another fundamental hazard of the time trap is the temptation to build project estimates based on time logs from previous efforts. On the surface, it appears to make perfect sense: If it takes a developer X hours to complete task Y, then it would stand to reason that similar tasks will take a like number of hours.
But, of course, no project is ever exactly identical to those that have come before. Natural differences introduce an element of unpredictability that, unless addressed, can render estimates imprecise at best, and wildly wrong at worst. Even if teams can achieve high accuracy rates for actuals versus planned against tasks, there is no good way of leveraging that data to improve the estimation process. For instance, if a team’s actuals exceed its planned by 10%, should a 10% pad now be added to the next estimate? It’s just not that simple.