Last Friday morning I presented a second Scrum talk on the topic of “Scrum: A hands-on look at Scrum for Team System.” at the Queensland VSTS user group. As usual there was a good turn out of people (for an 8am Friday morning start) and the presentation went pretty well, with lots of audience participation. Conversation was based mainly around estimating, story points and the product backlog and the dreaded talk of measuring actual time spent on tasks.

Measuring actual time spent on a Scrum task is a question that comes up often. In this session the comment was in relation to where in team system the actual time could be recorded? The answer surprisingly enough for a Scrum tool is nowhere (unless of course you add it yourself). I always like to dig deeper into the details of why people want to track actual time spent on a task, it normally comes down to two reasons :

1. To improve your own or the teams estimating skills. People believe that if they look at their estimate for a tasks and the actual then they will be able to improve their estimating.
2. A lack of trust between the line management and the team. The management want to know who is doing what and how long it is taking them.

Don’t bother tracking actuals. Obviously a lack of trust needs to be addressed elsewhere in the process. A Scrum team should be empowered to do whatever they like within a sprint (within the confines of the corporate standards) to achieve their sprint goal. What they do in the sprint should be of little importance to line managers. If the goals are not being met, then the team should identify areas in which they are failing. Are they taking too much into a sprint? Are impediments not being removed? Has their velocity been estimated too high?
As for improving your estimating skills (1) Yes tracking actual time spent can help you improve your estimates, but a team should not be asked to do this. The individual team member or the team themselves should be the ones who suggest doing this for a limited period of time only. The teams and management should remember that estimates, really are estimates and that nothing remains constant in the software world. So a task that took 8 hours one sprint, may not be exactly the same next time as they underlying framework or skill set of the person implementing the task could have changed.

Jeff Sutherland has a very interesting article on Why timesheets are lame. It’s a very interesting article of which my favourite comment is “developers have to fake the time to fill them out properly”.

One very interesting tool was introduced by Matthew Rowan called TFSWorkingOn. This is a cool little system tray application that allows the developer to easily record time against a work item in VSTS. More information on this great little tool can be found here on here and is also available on Codeplex