Planning poker is only useful in the context of who may be doing the work, and even then I'm not sure how useful it really is. What is an 8 to one dev may be a 5 to another, as one may have a better grasp of the problem space than the other. In short, one shouldn't assume equality across the team for ability to do given task.

In theory yes. Back on earth: I can argue that each task is 13 points. Usually this goes to being a pissing contest. The person that is deeply familiar with what needs to happen and has written this down (assuming written down not a one line to fix somthing) to be "estimated" probably is in the best position to acually do it/fix it. Also it's an insidious way to get the drones to fight each other trying to one up and show how smart they are. The person assigned to fixing it should estimate it (ie I have completely silenced "10x" developers by just telling them to just pick it up and do it if it's so easy).

I do like the planning poker for the same reason. I just find that people use story points overly granular. E.g. when using Fibonacci series, what is the point spending time discussing the minute difference between 1,2 and 3 points.

What I have liked in the past, is just using small, medium, large or unactionable.

Or with the right team/managment, not using estimates at all, just have people pick up the tasks they feel confident that they can get done within a given time frame after having the discussion in the group about differing opinions on complexity.

There's more difference between 2 points and 3 points than between 5 points and 8.

If you're looking to fill an arbitrary bucket, relative size matters most.

Our team had so many planning poker sessions where we spent 12 people * 2 dev hours trying to figure out whether stories were a 2 or a 3, management finally said it is always a 3. We were literally spending more aggregate time trying to decide effort, than the actual effort it took to complete these tasks.

2 and 3 are equal. 5 and 8 are equal. The question is simply "Is this a couple days, the whole week, or the whole sprint?".

The only reasonable estimates, ever:

+ That's trivial, it will be ready for testing before lunch.

+ I know how to do that, should be ready tomorrow/next day.

+ I can see how to do that but there are lots of other constraints - at least a week, might be more.

+ It's a big project, needs more planning and specification before it becomes a series of estimable tasks. Let's do that.

+ That breaks other things we care about. We need to prioritize and be ready for rework.

If you want, you can call these small, medium and large.

I completely agree with these levels, but disagree with mapping them to “small, medium, and large.” That’s a lossy compression if you will, and the heart of the problem. A shorthand might start with good intentions, but rapidly is muddied by conflicting interests.

5-8 just means that you think that the task is getting a bit big.

Have a think and can you split it into two smaller tasks for the juniors to pick up.

How is it helpful to the entire team for everyone to pay attention if adding a feature is 3 or 12 points? It's the one thing that wastes so much money and time. In the end it's 3 points. Thank you everyone for wasting $5,000