[abernard1]

> If you consistently get it wrong, either:

> 1. You're not breaking down the work into small enough chunks to properly think about how long it will take

This is exactly what waterfall was. It pre-planned all the small tasks beforehand and required stopping the world and replanning everything when something changed.

Agile was an attempt to move away from that and create a feedback loop where you do some limited work, learn something from it, and then do another thing after you've internalized what you learned. (Original "sprints" were a coordination mechanism between departments that was applied in the automotive industry: there was lots of dead space in-between them). The whole point was the iteration was small enough that it didn't actually matter if your estimate was correct or not.

This bastardization where Agile has become synonymous with estimation accuracy is completely against its original spirit. People have started to care about estimates because Software Project Managers wouldn't have a job if there wasn't a need for heavy-handed planning sessions.

[pas]

I think the estimation accuracy is not the main point nowadays, but instead the simple fact that the viability/rentability of every project matters, and even if there's an up front pile of money to spend (quarterly/yearly budget), there are probably multiple competing ideas on what to spend these - and of course these usually consist of and involve software and its development.

Of course this is why having a low-fluctuating empowered team (project ownership, refactors, etc) can usually deliver changes faster and with lower cost and with greater consistency, than every time doing a new project (which might involve new people who never saw the stack, nor the business domain) to modify something on a system.