On Time Tracking with Agile
by Olga Belokurskaya
Progress tracking is essential for Agile development. It helps understand whether a team is doing the things right, find tough places in current iterations, and estimate the approximate dates of the release. As one of the backgrounds of agility is increasing efficiency and minimizing waste, time tracking is a necessary part of software development lifecycle. Time tracking powers accurate progress information by gathering information of the time spent on this or that part of the project and showing real project progress.
Many development teams use various types of time tracking, time reporting software, timesheets, etc. to manage Agile projects. Time reporting information allows estimating costs, counting salaries, forecasting the resources required for projects. But this is possible only when the time tracking is well-organized across different organizational units.
Not long ago I’ve met such thought in the web that agile time tracking should only track what is required. In other words, there should be gathered only time tracking data that is just enough to track the project process. Well, that makes sense if a team is focused on a single project for a period of time. Then the actual time spent on each task isn’t as important as velocity in terms of story points (abstract measure with no relevance to actual hours). The latter allows gathering enough information for accurate estimations and profitability calculations. Thus, there is no problem with managing even fixed bids projects using story point estimates and velocity. But still, this makes sense only if done accurately.
And, here comes, probably the main issue with time tracking – there are not so many people who like doing it. I’m sure, almost everyone who has ever dealt with time reporting had such situations at the end of the week (two weeks) when s/he had to remember what was done during the period. And very often this comes out of the imperfection of time tracking software (bad tasks categorizing, user-unfriendly interface, etc.). In other words, software is not so quick and simple to motivate people using it. Actually, it’s a charge of those responsible, to find the software that answers all team’s requirements (well, that’s in ideal world). Anyway, there is a choice, there plenty of tools, starting from TFS templates for Agile and ending with various proprietary and open source solutions.





