For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.
Would you feel it fair, when you require an estimate, to have to say what decision you'll make with it?
Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made.
The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.
I’m talking about particular user stories, not the overall estimate.
For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot.
My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc
I've never been in a situation where adding db crud was its own user story. Usually, we group this and the button (and the metrics necessary to trask feature use) in a single item, and pair people so it can be shipped in one go.
A big difference for what?