Is a developer trustable for estimates?
I’m a voluntary provocative on the post title; you can read Udi’s post. Udi also refers to a prior post of him (Don’t trust developers with project management) which is of interest.
This is all about estimates done by developers. I’m hearing frequently that estimates from developers are always under estimates and should be compensate by a factor. I thinks the “underestimate” assertion is not always wrong (maybe often true…) but I disagree on the way to handle such behaviour. The management is trying to balance the initial estimation with a magic factor which should make current and future project predictable and delivered on time. This approach can be discussed for its efficiency, but I’m mainly surprised on the fact that it can be summarized this way: a manager can’t trust developer estimates, but we can trust the manager. This is to me a very strange position for a manager: how can we trust more the guy which knows the less about the “hand-on-work” when he use a magic factor? More over, why hiring a developer if you don’t trust his(her) estimates?
I think this is the role of the manager (or project lead) to improve and support his(her) team. That means to me: learn them how to be more accurate in there estimates even if finally they will use a magic factor. This can be done also by providing data and tools to allow the team to understand better their estimates errors and be more accurate in the future. The manager is also the gate keeper for all changes requested that have an impact. I do not mean reject any change, but track them to have a clear vision of the project progress.
September 9th, 2007 at 12:45 pm
I just wanted to reiterate and say that I don’t believe that developers underestimate. Rather, I’d say that in order for a feature to be “done”, several people need to be involved. Thus, I don’t think it is the responsibility of the developer to estimate the amount of time (hours worked, and calendar days) it would take for the feature to end up done.
That is why I suggest measuring the amount of features actually done in a period of time by the whole team in order to predict when other features will be done.
Does that make sense?
September 10th, 2007 at 12:45 pm
That totally makes sense, my intend was to show that some dev manager and PM are compensating in a suprizing way with a magic factor. A better approach to me (totally compatible with your) is to help the team to learn itself (including that develoment is also test writting, test framework enhancement, CM…etc). Basically, communicate more inside the team with all different profiles, to allow better communication outside.
So I agree that the developer do not do the estimates, but the team does it.
On your post, mesuring features accomplishment is key, and I think it worth extending it to all activities of the team. Obviously it depends on the way the team is organized, in charged of…etc. You may have a low velocity from a features perspective for an iteration because you improved your test framework (introduce a new testing third party for mocking for example), or fix tricky customer defects…etc.
September 10th, 2007 at 7:17 pm
It is exactly for the reason that you mentioned that I look at average velocity over the last 3-4 iterations.