>
Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat.I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation.
I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months.
What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide.
Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed.
But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous.
I'm not saying anything new here. But I understand better where you were coming from.