"points" are just a way to avoid being held accountable. If we were to use hours (even buckets of hours, aka: 1, 2, 4, 8 hrs) we'd be better off. It'd be more transparent and while it may differ between team members, we can hold people to account who over / under deliver based on their estimations. The entire point is to estimate velocity (supposedly), so why not have a feedback mechanism that's let engineers learn to estimate better; instead of using an abstraction.
I for reference, have multiple agile certifications and just don't understand.
That sounds wildly micro-managey. I often don't know how long something is going to take until I dig into it; sometimes I don't know how long something is going to take until I'm almost done. The ambiguity/fuzziness of points is a feature, not a bug.
If I'm going to be "held to account" based on my estimates, I will optimize for producing work that matches my (naive, uninformed, up-front) estimate, rather than producing the _right_ work. This will last for a few months, at which point I will realize I'm burned out, working inefficiently, and writing bad code, and I'll find a new job on a different team that doesn't treat its employees like train conductors.
True.
But on the other hand an experienced developer usually can give a reasonable estimate. An if he says: "about two days maybe a week" then that is you best estimate. Using story points is just another complication.
And points do not stop anyone from holding you to account, if that is what they want to do.
Because now your guessing on minutiae and will inflate the hours to reduce pressure. Or spending enough time to solve the task "estimating" the work due to the need to derisk it. Thus alleviating the pressure of being accountable.
Complexity points has value since they can be used in aggregate to estimate what a team is capable off, assuming the estimations on average are consistent between cycles.
The point of the numbers is to be a tool for the team, not management. If they get reported up it should be at most one level (immediate supervisor/lead, not middle or upper management). The information provided, assuming that the team is moderately consistent in their point assignments to tasks, is: Are we holding steady, slowing down, or speeding up?
Steady and accelerating are the good cases, slowing down leads to questions. "Why did we slow down?" "Oh, that task we gave a 1? Turned out it was actually huge because it involved X which none of us noticed or was more broken than we realized. Took up the entire time." Or "We brought two new people onboard and were spinning them up. They aren't productive yet and our experienced people were spending the time bringing them up to speed. We should get back to the normal flow in a few weeks." Or "We have no idea" which drives more questions. Or "We brought on two new people and spun them up, but now their estimate inputs are changing how our tasks are scored so it will take a bit to figure out our new baseline."
All of that assumes the team tries to be consistent in their scoring and is reasonably stable in its composition. If you're changing out team members frequently, then there is no value from points (because they won't be stable). If your team decides to fuck with it by rolling a die and using that for each one, then there is no value either.
When you change your processes in some way (and assuming a stable team and scoring), then you can also use the velocity over a series of sprints to evaluate the effectiveness of the change. If it hurts, you'll see a long term decline, and if it helps you'll probably see an initial decline (learning) and then improvement.
The point of "points" is nobody can estimate how long a task will take and it gets worse the larger it is. So it's better to have reference tasks of a certain size and complexity that you do know how long they took and compare to those to get a general idea. You could use hours in that context but it's trying to make you think is terms of size and complexity not hours.
I for reference, have multiple agile certifications and just don't understand.