While your examples I'm not sure are super relevant from a software development context. I think you're pointing out that the estimate would help you decide when you need to start so you are done before the "real life events that needs the thing".
Is that correct?
Like for example I'm not sure it's useful to learn that no, you will not be ready for the Christmas event. Or no the cruise ship will not be ready in time. But it might be useful to know: "If I want to be ready for the Christmas event when should I get started and how many developers do I need?"
That's a good example I guess, though I haven't seen this issue arise very often in software. I could imagine someone needing to know when to start feature freeze and prep work for scaling up leading up to a big sale event if you run an online store for example.
My take on this is that asking devs to guess that time would obviously not work. And if you did this type of forecasting for any other discipline, you'd instead gather historical data about how much time things took in the past and plot that to forecast how much you'd think it takes in the future. Which is a process that can be done without needing to ask a dev for their personal not data based guesstimate.
I have seen two software examples first hand. Usually it's because a feature can have much more value at a very specific date.
The first one was a feature for one of the minor verticals of the company product. Basically, something that would be nice to have and would be done eventually, but not a priority. However, the big annual trade show for that vertical was coming up, and the company could have a slot for a conference/demonstrate a feature. Marketing/sales were pretty convinced the aforementioned feature could be a big hit at the show, and provide lots of exposure. So we were asked whether it was possible to have it ready by then. If we could, then it would have a lot of value and would be priority 1, otherwise back to the backlog because it would be much harder to advertise it outside of the show.
Second example was caused by the reduction in VAT in Germany last year. Having internationalisation/German translation all of the sudden became pretty valuable because that would help push even more products in Germany.
I haven't seen this issue arise very often in software
No? Maybe not if you're a software-only company. But for pretty much every hardware (a gadget, a car, a rocket, whatever), the software is part of it and it aint working until the software is.
If you don't want your product to be held shipping because the software isn't ready, you better have some way of estimating when it's going to get done so you can either trade features, personell, or even just knowing that there's no point rushing the hardware because it'll be done way before the code anyway.
Inter-team dependencies. Marketing pushes. Customer commitments. New sales dependent on certain features. Building features to increase TAM. Partner commitments for interoperability / joint deployments. Even presentations of your roadmap to customers and prospects to get them bought into your vision of where the product is going.
There's tons of things that require broadly knowing when X is going to be done beyond capacity issues.
The above are reasons a business needs estimates / rough delivery timelines. I'm not sure how my discussion of the value of estimates is relevant to the quality of them.
While your examples I'm not sure are super relevant from a software development context. I think you're pointing out that the estimate would help you decide when you need to start so you are done before the "real life events that needs the thing".
Is that correct?
Like for example I'm not sure it's useful to learn that no, you will not be ready for the Christmas event. Or no the cruise ship will not be ready in time. But it might be useful to know: "If I want to be ready for the Christmas event when should I get started and how many developers do I need?"
That's a good example I guess, though I haven't seen this issue arise very often in software. I could imagine someone needing to know when to start feature freeze and prep work for scaling up leading up to a big sale event if you run an online store for example.
My take on this is that asking devs to guess that time would obviously not work. And if you did this type of forecasting for any other discipline, you'd instead gather historical data about how much time things took in the past and plot that to forecast how much you'd think it takes in the future. Which is a process that can be done without needing to ask a dev for their personal not data based guesstimate.