To me it the estimates themselves don't really matter. Everybody already knows if something is gonna be worked on or not (at least kind of). The value I find from estimates is they encourage the team to discuss how something is gonna be built.

The best moments are when everybody estimates that something is "easy" except for exactly one person who says "this is super hard". Then there is a discussion about what the "easy" camp might have missed or perhaps the shortcut the "hard" person didn't know about.

At the end, everybody walks away understanding a little more about what the rest of the team is working on.

Exactly!

The issue is when organizations or bad POs or SMs subvert this and make it all about estimating everything exactly in story points where everybody has to be on the same page on the fact that 2 story point means 2 person days of work. And that is the only thing that estimations are used for at these places and every team has the same scale and get compared on how many points they deliver each sprint. And they press the teams for estimating ever smaller.

That is the kind of environment that most of the devs that hate Agile or Scrum are living in and it's no wonder they hate it. It's completely against the spirit of Scrum and agile so we can't blame them. Unfortunately they blame agile which was a try to make things better for them.

I do it properly, but I also usually work alone, or in very small teams. I have the luxury of setting the goals, and moving the goalposts, when needed (often).

Waterfall is almost required, when you are crossing the streams. Merging separate workflows is a fraught process. You need to know what will be delivered, when. I spent most of my career, working for hardware companies, and saw this every day.

Truly agile processes don't really lend themselves to that; which is actually kind of the point.

But the real deal, is that high-level managers and non-tecchies can't deal with Agile.

Managers have a lot of power. If we don't help them to understand the process, they will make decisions, based on what they know.

> You need to know what will be delivered, when.

It is valuable to have engineers who know how to decouple individual pieces to eliminate (reduce) these dependencies. These dependencies are almost guaranteed points of conflict and risk for the project.

Tell that to a hardware manufacturer that is developing a camera, with firmware, three different processors, drivers, APIs, SDKs, host software, lenses, speedlights, marketing materials, packaging, distribution, documentation, etc., while coordinating manufacturing lines in three different countries, and engineering efforts in two.

It can get ... intense.

> First thing that happens when implementing agile are estimations

I'm usually the first to chime in that all estimates are lies, but small estimates (i.e., per-issue, not per-project) easier than big ones.

It really helps to use vague terms like S/M/L/XL or bike/car/plane or whatever. If you say an epic will take 6 months, it is very likely that in 3 months someone will ask for proof that you're halfway done.

But once you have abstract S/M/L/XL estimates for some tasks, what do you do with that information? How many S tasks are equivalent to 1 M task? If the team completed 3 M tasks and 3 S tasks last sprint, how does that help you plan for your next sprint? While story points have their own issues, at least tasks' relative size differences are clear and different tasks of different sizes can be scheduled.

Story points are relative measures (at least when you do it 'right').

What is so different from estimating things as 1/2/5/8 or S/M/L/XL?

S (or 1) is roughly half as hard as M (or 2).

M (or 2) is roughly half as hard as L (or 5). Notice how 2 is not exactly half of 5. Just roughly.

And so forth.

And the point is that you can't say how many S are exactly equivalent to how many Ls. Estimates tend to get less precise the larger they are. There's usually more uncertainty built into large estimates which means once you do the work it might be much faster or much slower because of things you didn't look at very closely when estimating. While small things are easier to have a complete overview of and the estimates are more accurate.

A recent example from my work. There was something the team unanimously estimated as L. I knew it was an S. I knew the code though and they didn't. I let them put the L estimate on it. When the sprint started and I had some time I did the task myself and it really was an S in the end. But that's fine. They 'priced in' the uncertainty. If one if them had done it, it might very well have taken them longer because if not knowing the code as well.

You don't; you ease your executive/sales/etc partners into the new world where they get better software, faster features, and fewer outages, but they give up release dates and micro-managing the roadmap. Calling an epic "Large" instead of "237 story points" is a way of forcing yourself to accept that you only have a rough idea of how long it will take.