One of my colleagues has suggested timing how much time each team member spends on each user story. This seems to me likely confusing for the dev team during the iteration, and misleading as a metric for story estimation in future planning meetings.
Do any of you have experience with such a system and any thoughts on how useful or disruptive it might be?
It is only necessary to have some measure of how long a story took to implement so you can compare it to the initial estimate. Armed with this information you can then make better estimates next time.
For example, for this iteration you decide that story A will take 2 days and story B will take 4. However, it actually takes 3 for both of them. Then in the next iteration you can look again at the remaining stories and re-estimate them based on this information. If there are more stories like "A" you'll need more time (or get less done), however if there are more stories like "B" you'll need less time (or get more done).
You shouldn't log time against the individuals in the team, but against the story. I know some say you shouldn't log any times, but unless you've got developers with perfect recall their estimates of future tasks are going to be skewed. Having numbers allows you (to a certain extent) to normalise estimates.
In Scrum, all of the effort is focused on looking forward. Actuals, therefore, have no intrinsic value. What is useful about actuals is to use them to refine how a team does its estimates.
Even there, though, a detailed analysis of how individual estimates faired against the actuals is of little value. As a practical matter, most teams learn to live with their estimation accuracy and populate their Sprint Backlogs accordingly.
For instance, let's assume that a team habitually over, over, over estimates tasks. They plan 30 man-days of effort for a 5 person team over a 2 week Sprint (5 * 6 (assuming 60% utilization of the 10 business days)) and find that everything is done by day 4. So when they plan the next Sprint, they say to themselves, "Well, we were able to complete 30 days of estimates with lots of time left over so let's put 60 (estimated) man-days of tasks into the next Sprint and see what happens". Over time, they'll learn how their estimates relate to how much work they can get done in a Sprint. It doesn't matter how bad the estimates are, as long as they are consistent.
Retrospectives are the place where the team sits down and looks at their estimates and how they want to deal with (or not deal with) accuracy. The only important factor, though, is that they figure out the right amount of tasks to put into the next Sprint.
I did it in my very first Scrum project. It didn't provide any value. This technique make sense only if you want to reuse that knowledge for next estimation but in such case you must estimate in hours on very low (task) granularity which is not possible.
We do it on our project. The managers love it, because they have spreadsheets full of numbers. I have seen no evidence that it actually helps the project run any better.
You must ask him why he want to measure how much time they spend on user stories.
The only valid reason I see, is to check productivity. If he really wants to calculate productivity individually like that, you must stop using Scrum.
Scrum is team centric, not individual centric. It works because of that.
I can imagine only two uses:
1) If you keep some kind of story points or complexity points for each stoyry, you can get some kind of average or range of time required for each complexity point . This could be useful in estimating future tasks.
2) you can calculate every empoyeese prediction success: The time they predicted for a task v/s the time they actually took to finish this. I don't see how that will improve the process but it can be used as a reward/penalty point during appraisals.
