A member of a new agile team asked the Scrum Development list how to keep track of the actual time engineers spend on tasks, and how this relates to the agile concept of velocity. Velocity is the agile metric for tracking how fast the team is completing features, and thus how long it will take to complete a project. The group's opinion was that tracking time spent isn't necessary or useful.
The original poster explained that his team estimates the size of their stories using story points. As the team completes stories, they tally up the associated story points. This tally is then used to calculate the team's velocity:
...the team's velocity is roughly the amount of work the team can do per sprint. Maybe something like 25 Story Points / 4 week sprint. That number can be used to help gauge how much work can be taken on in each subsequent sprint.
So far, so good. The poster goes on to describe how the team's stories get broken down into tasks, and these tasks get estimated and tracked in terms of hours:
We've been using a burndown chart, part of which is having each team member write down time remaining per task each day. This is entered into a burndown chart spreadsheet. But, that just captures data for the burndown, it doesn't help with velocity.
This confusion exemplifies why some agilists, including Ron Jeffries, recommend not estimating or tracking tasks at all. George Dinwiddie added his view:
If you make the stories small, then you don't need to track hours in your burndown. I find teams do better just tracking stories, and they don't waste all that time re-estimating hours.
In the discussion thread, Ron and others point out that all the information needed to make useful projections in captured in "25 Story Points / 4 week sprint". This is the team's velocity, and is exactly what is needed to predict how many stories this team will probably be able to complete in the future.
Does your team track task estimates as well as story estimates? Leave a comment and share why or why not.