In particular:
> Estimates are to be avoided at all cost.
How is an executive supposed to decide what I should work on next if I don't provide estimates of the things that I could work on?
Besides that, I wouldn't like it if I asked when I'd get my next paycheck and the response was, "You'll get it when you get it. Leave me alone."
Perhaps try sizing via t-shirt sizes, S, M, L etc. and then build up some team historical data on how long it takes everyone to get something all the way to production.
The both the business and development team can point to the historical data set as the best indicator of history repeating and we can leave hunches and guesses out of it.
This correlates with your S, M, L thoughts. The Product Manager can then prioritise based on these (i.e. these three single point stories deliver more value than that three pointer) and points are internally calibrated over time.
I have to say though, that my team doesn't really have "deadline" releases and the PM releases any time we deliver something of value to our users, so it helps relieve some of the burdens about estimating i.e. When I point, I don't really care if the points don't end up reflecting time.
I dunno.
Maybe ask an executive at one of the many companies that have scientists or mathematicians on staff how they do it.
My father has been an engineer (not in software) for decades. I haven't asked him about this yet, but I'm guessing he has to provide estimates for his projects.
My point was that we cannot really, because we are not engineers. Nothing in what we do is even close to what civil engineers do for example. Neither our tools, nor our workflows, or our constraints, really nothing.
I think the day we decided to call ourselves "engineers" we made a mistake, that's it.
But it's a lot easier for a manager to conceptualise how long a piece of art will take to do than a piece of code.
One significant difference is that you can just look at a drawing and know if it's okay or not. There's no test suite for graphic art. Drawing outside the lines is a stylistic choice. Compiler errors are not.
The stuff a graphic artist will be fastest at, and for which estimating will be easiest, is stuff they've done thousands of times before. Most programmers aren't writing code they've written thousands of times before, unless they're not paying attention.
Out of the creative arts field, I think programming is probably most like creative writing. The grander the program, the grander the equivalent narrative. Unlike a picture, you can't just look at a book and know if it's written properly, you have to read it through. Not only do you have to worry about grammar, you also have to be concerned that the narrative is internally consistent, and that it features the themes, characters, and dramatic situations specified in the brief.
Of course, the analogy still isn't exact. A novel doesn't actually have to be internally consistent, and the book doesn't crash if there are spelling mistakes. In fact, many novels written without taking spending the time and money to edit it properly will have plot holes or grammatical errors. A reader can fuzz past it, but a computer can't.
Ask a writer how long it will take to write a novel that is totally internally consistent, leaves no plot threads unresolved, and has no grammatical errors. They'll tell you it can't be done to schedule.
But yes, creative writing works as well. And creative writers are given deadlines.
This "Longflow Manifesto" would be fine (in my opinion) for programmers who are happy to get paid only on delivery, but how many are happy with that?