I think you might be confusing sprint review with sprint retrospective? What you describe is the sprint retrospective, and when teams are autonomous enough to actually act on their pain points, it's easily the most useful scrum ceremony, IMHO.

Sprint reviews are really kinda just a wankfest where people show nice graphs and demos for an audience that either already knows or doesn't care.

> it's easily the most useful scrum ceremony, IMHO.

Agreed. I would kill almost anything else from scrum (maybe weeklys can stay too. Sometimes they are useful), but sprint retros stay. And also agreed about the uselessness of sprint reviews. I've never been in one and thought later that I've learned anything or was useful to anyone in there. It's like going to church without being religious in villages. "The community would look with disgust at us if we weren't there on Sunday. So, we are there."

Planing poker is the one ceremony that I find consistently helpful. Listening to different devs discuss why they think something is 13 points or 3 points is helpful to the whole team. You could change the names of all the parts of the meeting, but having the discussion about differing opinions on complexity is so helpful.

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

>The whole point of...

there are many things that in theory have a particular point but that when put in practice most often do not have any point at all - in such cases opinion seems to divide between those who complain that the people who put things in practice do so incorrectly and those who feel that if the practice when implemented tends to be wrong then it is the fault of the theory itself.

I personally hold with the latter view.

About sprint reviews in particular (not retrospective), do have a point in theory? I have never found anybody that can point to any.

AFAIK, everybody that do it is cargo-culting.

The theory of identifying something as being shit and then removing it is a bad thing?

That is not the theory, that is the goal. Sprint reviews have a goal of identifying something as being shit and then removing it, they have a theory as to how this will be achieved which is the sprint review process.