If you can predict work then you should automate it instead of repeating it.
If you can’t predict work then attempting to do so is a waste of time.
I think this is a false dichotomy. Not all work that you can estimate can be automated.
Case in point:
If I was given a new project to work on with requirements and mockups that have been fine-tuned through deliberation, then I would immediately break down the entire project in terms of stories.
Then, I would verify the project breakdown with co-workers and get story points estimated for every story, making any adjustments as needed through this collaborative process.
By the end, I'll have an entire project represented in story points. Using either a sensible average velocity of the team on a previous project or a gut estimate of a velocity, you can pretty accurrately predict the length of a project, providing some padding for a low and high estimate.
Now, a project to, let's say, integrate a UI based on some mockups with new APIs that are being built cannot be automated--otherwise, our jobs wouldn't exist.
Is the estimate going to be perfect? Not always, but I have found the process I have described to get you very close. If it's off, was it a waste of time? By no means! We would have an accurate roadmap of the work that needs to be done, and often, the generated stories will have included valuable implementation hints/pointers by having gone through the process. It also helps set an appropriate expectation for the team even if it can flex.
Upfront detailed breakdowns rarely, if ever, reflect the reality of how things go - and TBH are about as futile as estimates. Thought processes change, approaches change, requirements change, simpler solutions are identified, etc. Only extremely high level breakdowns serve any kind of purpose in my experience.
Development (as opposed to simple ’building') is a very organic process, and should be allowed to proceed as such.
I think this is a false dichotomy. Not all work that you can estimate can be automated.
Case in point:
If I was given a new project to work on with requirements and mockups that have been fine-tuned through deliberation, then I would immediately break down the entire project in terms of stories.
Then, I would verify the project breakdown with co-workers and get story points estimated for every story, making any adjustments as needed through this collaborative process.
By the end, I'll have an entire project represented in story points. Using either a sensible average velocity of the team on a previous project or a gut estimate of a velocity, you can pretty accurrately predict the length of a project, providing some padding for a low and high estimate.
Now, a project to, let's say, integrate a UI based on some mockups with new APIs that are being built cannot be automated--otherwise, our jobs wouldn't exist.
Is the estimate going to be perfect? Not always, but I have found the process I have described to get you very close. If it's off, was it a waste of time? By no means! We would have an accurate roadmap of the work that needs to be done, and often, the generated stories will have included valuable implementation hints/pointers by having gone through the process. It also helps set an appropriate expectation for the team even if it can flex.
Upfront detailed breakdowns rarely, if ever, reflect the reality of how things go - and TBH are about as futile as estimates. Thought processes change, approaches change, requirements change, simpler solutions are identified, etc. Only extremely high level breakdowns serve any kind of purpose in my experience.
Development (as opposed to simple ’building') is a very organic process, and should be allowed to proceed as such.
I agree. What I'm saying is it's you're not stuck between no estimates and a perfect crystal-ball vision of the project.
A detailed breakdown will give you a more accurate picture than no breakdown at all, even if things change as time goes on.