Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
What's the point? Why time anything? Useful for what? – S.Lott May 17 '11 at 11:53
I log all the time spent regardless of the actual methodology used. I find it very useful for a lot of stuff. – Pavel Shved May 17 '11 at 16:14

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.

share|improve this answer
Scrum zealots say that NO MEASUREMENT should take place. – Peter K. May 17 '11 at 12:55
@Peter K. - fair enough, but unless all developers are scrupulously honest to themselves about how long a task took, their estimates for future tasks are going to be skewed. I don't mean you should be exact or log time directly against individuals. – ChrisF May 17 '11 at 13:01
I wholeheartedly agree! I just came across this peculiarity of Scrum recently and was mystified as to how they can claim to make accurate estimates if they don't measure how much time they spend. As you say: future task estimates will be off otherwise. – Peter K. May 17 '11 at 13:17

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
So you measure how much time the team spent? – JeffO May 17 '11 at 17:06
No since an iteration is time boxed. I measure how much points they completed to adjust velocity, in order to plan net iterations accordingly and update the release plan. – user2567 May 17 '11 at 17:08

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.