If it assumes remaining work is equivalent in time to done work (notion of velocity), it's (in my view) very optimistic. People learn the nature of the beast as time progresses. Collective learning happens slowly. A lot of important work is usually only discovered and planned in the second half of the actual (not original) timeline. A lot of important stakeholders are naturally only introduced into projects close to its finalization, which creates a flurry of new activity and discoveries. This makes projects late.
But where that real halftime is - most people I worked with rarely know. I was no better, I also rarely knew.
The only way to manage this I found was the basic rule: build, demo, decide what to do next. Don't get attached to original backlog and grand plans for the future. It won't work that way. Just build and make it work, launch ASAP, get decisions on a ~weekly basis done. Ignore long term planning. It's not helpful.
Sadly, few business folks want that of course :)
Secondly, telling business that we can't estimate accurately is more useful than saying we can estimate accurately and being wrong (which is guaranteed). It's a tough sell but it's necessary.
As for consistent, my point was if you have 100 SP in backlog, delivered 50, then I contend you are not in the mid-point of the project. This is a dangerous assumption. You don't know where you are in my experience.
I’ve been trying to distill this into a framework that is accessible to both development and business folks [0]. I've used it a few times and it has resulted in a few projects getting cancelled due to a massive difference in initially expected cost and post-analysis expected cost.
0 - It's basically just Scrum oriented towards providing upfront estimates. https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-es...
> Sadly, few business folks want that of course :)
Business folks want this usually because it's their money you're playing with.
> Ignore long term planning. It's not helpful.
So, no don't tell people to ignore long term planning otherwise people who give you money are going to stop giving you money to "build, demo and decide". Unless you're on your own dime (e.g. you pay yourself or are self funded), then I wouldn't take this advice.
The theory of story points (which originate outside of Scrum and are not part of Scrum proper) is that task-specific time estimates in creative intellectual work are extraordinarily unreliable and expending more effort on them doesn't improve them, but broad-banded complexity class evaluation mixed with empirical observation of the teams velocity produces time estimates that are (while still extremely fuzzy) both better and much lower effort, once you have the basic tracking in place, than task-specific direct estimates.
The “dogma” you report seems like something that might be a derivative of that that has lost track of rationale and purpose, reducing it to a cargo cult practice.
Planning poker and such are useful as they encourage the team to discuss differences and help identifying stories which are too large.
But that obviously won't work from the start, and it won't be accurate... Just better than nothing and (hopefully) better than what a programmer will estimate in their head.
And IME, it's a lot less stressful on the programmer to estimate points rather than time.
How to turn your organisation into a cargo cult 101.