[vp8989]

Anecdotally, I've observed across my ~12 year career so far that an emphasis on estimates and estimating is negatively correlated to productivity, lead time, velocity, impact, positive outcomes etc...

I suspect the reason is because management is trying to use numbers to justify bin packing more work to an already oversubscribed team. What never shows up in those project management spreadsheets is the very real and predictable cost of context switching and the increase in mistakes from dealing with a larger amount of in-flight work.

[PragmaticPulp]

> that an emphasis on estimates and estimating is negatively correlated to productivity

When the estimates and their accuracy become the primary goal, productivity is secondary.

My worst experience with this was a company that valued roadmap accuracy so highly that we were rated on our on-time delivery more than anything else. The inevitable result was heavily padded estimates and teams who carefully avoided doing any more work than necessary (yes, early delivery was technically negative points for your bonus). The pace of work was incredibly slow and methodical, but the company got their metrics optimized. Madness.

The opposite end of this spectrum isn’t great, though. There’s something about teams that pride themselves on no estimates and no deadlines leads a lot of people to spin their wheels forever. I’ve also been stuck on some teams with endless cycles of rewrites and refactors and switching to the latest language or framework every 6 months. We did a lot of work, but didn’t ship a lot.

There is a middle ground that is much nicer than either extreme.

[marcosdumay]

> There is a middle ground that is much nicer than either extreme.

That middle ground is focusing on releasing. It is done on a completely dimension from the "estimate everything" vs. "estimate nothing" duality of your post. So I really disagree with your characterization of it as "middle ground".

[candiddevmike]

Estimating and a lot of project management stuff is a form of procrastination for a lot of folks/businesses. It doesn't matter what fields the cards have or how they are arranged, the work still needs to get done, and all of this shuffling is just delaying the start of that work.

[AnimalMuppet]

That's only true if there's a fixed set of work to get done. But that's rarely the case. Often, management has N different things they could have done, and enough people and time to do M of them, for M < N. Which ones should they do? Well, whatever maximizes profits. So they (management) estimate income from each thing that could be done, and ask engineering (hopefully) to estimate how much it will cost to implement (or how long it will take, which equates to cost). Then they make a (hopefully) more informed decision than they otherwise could have made.

Look, there's lots of ways this gets done badly. I get that. But the idea itself is not nonsense.

[delusional]

That's an interesting thought. I've never considered it before, but estimation as procrastination might be a good explanation.

[rqtwteye]

Totally agree. My management mostly is interested in estimates and deadlines . They never engage in discussions about productivity or quality. This results in people continuing ineffective processes and other systems. It also encourages people to make tests pass at any cost or close tickets even when there are deeper problems that should be resolved.

In short, the focus on estimates

[0x445442]

Yep. If you don’t track the hours for The Process it’s just pure conjecture whether or not The Process is a value add.

[chasd00]

the thing is, management is accountable to a budget, timeline, and an ROI. They have to be able to say how much something is going to cost, how long, and how much they're going to get in return. Now, a person doing the estimation has to be able to take everything into account, down to the cost of context switching, but those three things are all that matter upstream. Also, the people doing the estimations have to be able to answer questions like "well, what can you do in, say, half the time?". It's not easy.