If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.
Relative sizing is still an estimate.
> They're for re-arranging the priority of stories and deciding which ones to do or not.
Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.
Not one which would attract any pressure.
If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.
If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.
> The non-technical managers and agile coaches are the problem.
No, shitty managers are. In fact, most of the utterly useless managers and leaders I've had have been technical who just assumed that management, soft skills and leadership are "easy".
> That's why the best software projects don't have them.
There's no one definition of "best" software projects. And something being good software doesn't mean it serves a products needs.
> Linux kernel developers don't run story ticket velocity poker sprints.
The Linux kernel works because the project management knows their audience. The project is managed differently and ran differently. If I drop into an email thread talking about a large feature and say "I think that will take 2 days" people will disagree with that. That's all planning poker really is - once you've decided to do something, have a gut check on how much work it is.