That's the problem. You have an opinion but no empirical evidence and you think your opinion is pretty good. There's plenty of material out there that is a bit more well reasoned that disagrees with your opinion. For example Don Reinertsen's books.
Most Agile estimates are pretty bad. But that's OK because it's still better than just winging it. One of the realities of working with real companies is that they have things like dead lines. Programmers don't like them. The don't believe in them. They are bad at delivering stuff on them. But they still exist. The reason agile/lean/scrum/etc. exist is to beat some sense into programmers completely and utterly failing to deliver anything on a predictable schedule. Bad estimates are the foundation of these processes. Where bad is better than no estimates and the rest of the process is about mitigating the consequences of the estimates being low quality.
> That's the problem. You have an opinion but no empirical evidence and you think your opinion is pretty good. There's plenty of material out there that is a bit more well reasoned that disagrees with your opinion. For example Don Reinertsen's books.
Wait - there is a large body of work that is better reasoned than a quick post dashed I off in haste before dinner?
> One of the realities of working with real companies is that they have things like dead lines
Using condescending terms like "real companies" is unnecessary. You know nothing at all about me or how I've come to my conclusions; you just make arrogant assumptions that you know better about this than I do. I'm open to being wrong and learning new things, but do you really think you have the Silver Bullet?
My experience over a large number of projects suggests that the whole premise that most commercial software project problems can be solved using technical, mathematical or scientific means is wrong. My opinion - which aligns with the results of large-scale studies such as the Standish Group CHAOS reports, the PMI Pulse reports and more - is that the problems with commercial software projects appear to be almost entirely social and organisational. Projects are too ambitious, too complex, and are executed poorly by inexperienced people. No amount of time spent on estimation is going to fix that.
I am unfamiliar with Reinertsen's work, but I think it's quite interesting that economics is not exactly a science either.
Most Agile estimates are pretty bad. But that's OK because it's still better than just winging it. One of the realities of working with real companies is that they have things like dead lines. Programmers don't like them. The don't believe in them. They are bad at delivering stuff on them. But they still exist. The reason agile/lean/scrum/etc. exist is to beat some sense into programmers completely and utterly failing to deliver anything on a predictable schedule. Bad estimates are the foundation of these processes. Where bad is better than no estimates and the rest of the process is about mitigating the consequences of the estimates being low quality.