- Middle management mover-and-shaker. Most recent technical contribution to a product: Some time in the last ice-age. Super power: secret meetings that lasted for hours, discussing how much all the devs were late, and who to blame.

- Underflunky. Ran daily stand-ups to gather status. Last technical contribution to a product: Never. Perpetually terrified. Super-power: "Since we need this done by the end of today, let's have a bunch of meetings about it. Are you available for an hour at 10, 2 and 5?"

- Fantastically technical PM. Last technical contribution to a product: Helped debug a gnarly problem over in the other building about ten minutes ago. Super-power: Writing intelligent specs that devs understood and that actually described shit that would work. Achilles heel: Incredibly over-worked and a burnout in five months.

We had one or two of the latter PMs on the last project I was on. They were great; every other PM did negative work.

I did get our underflunky PM to start calling our scrum meetings "Status".

But you have a point; a lot of places try to 'be agile', as something the devs do, without also including management. As a number of others in this thread even indicate. Management has to also change, or else there's a mismatch in expectations.

As a dev doing SCRUM, we report point totals, and allow the business unit to prioritize stories based on that, and based on the need for the feature. Point totals above 8 or so we try and break down into more stories. The only guarantee we give is that if we include it in a sprint, we will get it done in that sprint. We can estimate it at ~8 hours (~two days of a single dev's time; we build in slack, for meetings, context changes, dev tasks, and the unexpected), but we aren't guaranteeing that you'll have it in two days; it'll be the end of the sprint. Any more exact estimate is only for other devs, in case they're reliant on it being in place for something they're working on.