[bhanu423]

Excellent points, I think the whole point of SCRUM planning is to get estimations correctly and it is not as easy reading few articles on it. Hence involving a scrum-master is highly recommended who is usually a person like mikekchar who has done it multiple times atleast.

[paulie_a]

The scrum master has to have a fundamental understanding that 8 hours of work is not one day. It's generally interrupted by meetings, helping out a coworker, crisis mode on some bug and also generally fucking around with coworkers. When a Dev says 8 hours that should automatically be translated to 16-24 because they won't actually be able to be "heads down"

[mikekchar]

The interesting thing is that statistically, the things that interrupt a developer occur at a predictable rate. What's not obvious, though, is that you can't predict the completion of a single task. You can predict the completion of a statistically significant collection of tasks. If someone is asking "How long will it take to do X", where X is a single task and is banking the company on the reply, they are a fool. But if you ask "How long will it take to do 30 x" and you have some data to show how long x usually takes, then you can actually give some good replies.

Even more interesting (and I was thinking about this only 5 minutes ago), there are models for defect discovery rates. This basically means that when we write code we make software errors. The amount of time it takes before we discover the error is a random variable with a particular distribution. There are several models which try to allow you to determine how long it will take before you find 90% of the errors, for instance. I was just thinking that I bet the model for errors in requirements is probably very similar to the model for software errors and you can probably fairly easily model how long it will take you before you discover 90% of the remaining functionality that you need after you make the initial plan. Indeed, I've measured in a few groups I've worked on that for those groups they needed another 30% of the overall project time to complete tasks that were not anticipated at the start. Unfortunately I no longer have access to that data so I can' look at it in more detail.

(NB: 30% was just for those teams and those projects -- I don't for a second believe that the number is universal. The fact that it was similar for a few teams is probably coincidental.)