My discomfort with task estimation stems from the fact that the description of the task is usually not detailed enough, either because the domain experts overlo

My discomfort with task estimation stems from the fact that the description of the task is usually not detailed enough, either because the domain experts overlooked something or forgot to tell me, or because there are simply too many potentially relevant circumstances that have not yet been nailed down. Think of a rather innocent question like this: How much time does it take to drive the 500 km from A to B? -- How well could you answer that question for a particular case, even if you had already driven from A to B a hundred times? There is just so much that could be different this time. Still, some estimates can be made. And as the article also pointed out: Sometimes it matters a lot that the guess is right, or you need a big margin of safety (catching a plane in B), sometimes it doesn't matter at all (going to your cabin in B). Typically, the accuracy of an estimate cannot exceed a certain level, even when all relevant known factors are included: How many hours of sunshine may we get during our trip to Scotland in week 30 of 2023? As for estimating tasks in software development, my approach is similar, but not identical to the one described in the article: I give a worst-case and a best-case estimation, insisting that I do not promise anything because there might be unknown circumstances that are even worse than in the worst-case scenario. What is also very helpful is to divide a larger task into smaller subtasks and give an estimation interval for each of them. Typically the worst-case estimation is about twice as long as the best-case estimation. This seems to work quite well: Almost all of the time it turns out that the actual time spent was indeed somwhere in this interval. After a while, my clients get used to this kind of interval estimates and no longer ask for a single number. My criticism of the article is that the question "Why do you want to know?" becomes less important (but it does not disappear completely) when management is given an interval instead of a single number. It is up to them to decide whether they can live with the worst-case outcome directly or have to adjust for it elsewhere or scrap the whole project because it might not be worth it. I estimate the risks, but it is not my job to take them.