Escaping from the “How Long?” time trap
By Joel Semeniuk
March 28, 2011 —
(Page 1 of 3)
Related Search Term(s): agile, time-tracking
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.