[pwthornton]

This is generally why I don’t see a ton of value in trying to do accurate estimation. You’ll get better velocity and delivery not wasting your time on all of the faux story point estimating that scrum and other systems do.

The most proven way to do accurate estimation is to base new estimates off of previous delivered work (i.e. we’ve built this suspension bridge design before and it took us this long, so we believe a similar bridge under similar conditions would take similar amount of time). This is not what most places do (and most places don’t spend a lot of time after the fact really seeing how long each phase and part of the process took).

I’d argue that estimates should be removed from day-to0-day engineers and placed with program managers or others whose job is to see how long work has taken and make schedules and estimates off of previous known work.

The other way to get more accurate estimates is to build in systems and processes that require less and less custom work over time. So many software shops and tech companies never invest in this and every new major feature or project is heavily custom work.

[regularfry]

I've seen counting tickets work fairly well. If the team is well-practised at breaking work down into tickets below a certain size, chances are good that the number of tickets completed per month will be fairly stable. That reduces the problem to "can you break this piece of work down into tickets, please", which isn't framed as an estimation problem with any attendant "no, that estimate's too big, try again" pressure. The bonus is that you can tell when a team has a stable enough process for this to work by looking at their ticket history over a few months, and the "estimate" (projection, really) is provided by the team themselves, so you don't get into a toxic situation where a team feels they're being held to an estimate someone else gave on their behalf.

[ppeetteerr]

Depends on what you mean by accuracy. There is no bullseye with estimates. It's a means to set expectations and to show that you've thoughtfully analyzed the work.

Part of your argument rests on reducing novelty. However, that's already covered by the myriad of manufacturing process improvement books. Programming is unique because every project is novel. Any migration, any integration, is going to be heavily dependent on company culture and environment.

Like it or not, estimates are necessary to weight A against B, to scope, to plan marketing releases, to compete, to sell, to budget, etc. You may not get value from it as a coder, but that doesn't mean that there is no value in it.