The more I think about estimates and how I have been told to use them, the more I think about how they were a waste, and even a harmful thing, and the more I am convinced that me and my team should completely drop them. And this, for very different reasons.
I will just try to list some of them below:
– We can only measure a task that has already been done. This can lead to a more or less accurate estimate. But only if the person that has done the task is the same than the one that does the estimate.
– If we have done the same task several times, the estimate can be even more accurate. But the measure that we will use will only be an average of the several repetitions. That is why the estimate will not be perfect.
– In software development, what we have already done will have been automated. So what remains to do is what we have never done before. We cannot measure and estimate what we have never done before.
– We must trust the developers when they tell us that they do not have enough information to estimate. And this for several reasons:
The requirements can never contain from the beginning all possible scenarios for the use of the product. And certainly not when the first estimate is done.
When the developers are trying to estimate, they always realize that there are so many hypothesis on which they base their approach to developing the right solution, that they feel they must write some code to test different possible options.
- What should we not trust the developers when they tell us that they cannot give us an accurate estimate? Because we are managers and we think we know what someone can do or not? Because our position allows us not to listen to someone, only because we think that he is wrong?
- When starting to develop we often find better ways to do than we had designed.
– There are so many parameters to deal with for a project to be successful. I don’t know why but with estimates, stakeholders focus more on deadlines and cost than any other parameters (quality for example).
– Allowing flexibility in a project is not the same than starting with false – or at least very uncertain – hypothesis. Which estimates are.
– If estimates are only tools to define the price and the launch date, they should not drive the whole project approach. This unfortunately is the case. We should find other ways to set the price. And we should focus on the deadline given by the business. If they do not have a clear deadline, is the project really important? Or at least, should there really be a tight time constraint for such project?
– We are often forced to plan a very tight schedule for projects. Going too fast will only allow us to fail fast, which is not really the goal of a project.
– The programmer is the one who will program, and to do a good job he must be empowered. It is very sad to make him estimate his own time constraints and then force him to fulfill that estimate. The quality of work will be negatively impacted by this approach.
– When we start deigning the product with the customer and the program with the developer, the end date for this is quite unpredictable. So why at one point in time do we say “I now need an estimate”, knowing that we will continue to design the program and the product?
– If we could tell the programmer: the design is finished and the requirements will not change, we could perhaps ask for an estimate. But as we are not able of estimating when this work will be finished, we are not in a good position to ask for an estimate.
– I trust the developers (not only is it my gut feeling, but also, how could they trust me if I don’t trust them?). When I spend long hours or days with them to answer to their questions on the design and they tell me they are not able to estimate, I trust them. As I was a developer, I am well informed of the uncertainty of programming. If a developer told me “I can do this in 4 days” I would trust him. I am still waiting to hear that.