Escaping from the “How Long?” time trap

By Joel Semeniuk

March 28, 2011 — (Page 1 of 3)
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.

Related Search Term(s): agile, time-tracking

Pages 1 2 3

Share this link: http://sdt.bz/35401

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

Finding the right tool for the agile job Experts emphasize that tools should bolster the agile process above all else

Jim Highsmith: Agile Manifesto has served the industry well Looking back at its creation, the Manifesto cosigner expects agile to embrace continuous integration and enter new industries

Ken Schwaber on agile: It pushed success rates beyond 45% SD Times interviewed the co-creator of Scrum to see why agile improved development practices so dramatically

Comments

03/29/2011 06:00:07 AM EST

I tend to agree. As a developer myself I do find it very hard to remember what I did on a particular day, particularly by the end of the week. I hated it so much I actually invented a tool to do it for me (Qlockwork). With my management hat on, however, I can see why there is a need. If you can use an Agile approach it becomes much less of an issue and I believe you can use developers more efficiently. However, many businesses prefer a more waterfall approach where you know (or try to) exactly what you'll deliver and when, which does require very good estimation, and for that you do need feedback on estimate accuracy. Anne Currie http://www.qlockwork.com

United KingdomAnne Currie