An estimate is not a forecast: Linguistic philosophy in software projects

Not only in agile projects is it part of the normal procedure to estimate tasks (ticket estimation). Personally, I believe that estimates are always correct. After all, it is an estimate.

Escape the Feature Factory: Stefan Mintert english

Stefan Mintert works with his clients to improve corporate culture in software development. He currently sees the greatest potential in leadership, regardless of hierarchical level. He set himself the task of leveraging this potential after a career path that involved several changes of direction. Originally coming from a computer science background with several years of consulting experience, he initially founded his own software development company. In doing so, he realized that leadership is something that needs to be learned and that good role models are rare. It became apparent that his customers' greatest need for support in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was headed: improving leadership so that the people who develop the products can develop and grow themselves. Stefan has been writing for Heise as a long-time freelancer for iX since 1994.

Wikipedia understands this as the approximate determination of numerical values, quantities, or parameters by visual inspection, experience, or statistical methods. An estimate therefore determines something that is, not something that will be. An estimate does not concern itself with the future.

However, most managers I have encountered treat estimates like a forecast, i.e., a prediction about the future.

When the future then becomes the present, the estimate from the past is compared with a value that has developed at a later point in time. That doesn't fit together.

What managers actually want is, as mentioned, a forecast. Wikipedia also has something interesting to say about this: forecasts differ from other statements about the future (e.g., prophecies) in their scientific orientation.

If you, as a developer, feel pressured by estimates and how they are handled, you could try replacing estimates with forecasts. Of course, the effort involved will explode. And that's precisely the point: Many managers talk a lot and very gladly about how to estimate better. A lot of energy is put into this question. The question of how to work better often takes a back seat.

It sometimes seems as if the estimate (which is actually supposed to be a forecast) is more important than the product. The reason behind this is often the planning that is sacred to managers. However, the reasons for its failure do not lie in the execution of the estimate. An estimate is always correct, as I have also written elsewhere.

This also applies if the estimated value deviates from the true value. If I don't like that, I would have to replace an estimate with a measurement. This is not possible in this case because I cannot measure future results today.

So, if a ticket requires three times as much time to complete as was estimated (forecasted), the question is not asked whether the implementation of the ticket went well. No. The mere deviation from the estimate (forecast) is enough to discredit the work done. I consider this to be unhelpful, and in my opinion, software developers are called upon here to counter the abusive use of estimates.

The first step can be to make it clear that plans based on estimates are themselves estimates and not commitments. Anyone who sees it differently can, with a high probability, be prophesied a turbulent future.

Read First, Then Act

If you want to improve the topics I address in the blog in your company, join our Leadership Community for software development. It works even without a leadership position. With the code “heisedev,” you get the Heise discount for Interactive Members.

(rme)