[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.

[seadan83]

This is a cost centric perspective. I wish I could find the YouTube talk where Merck switched to a metric of "cost of not implementing" IE: how much revenue do you lose per day by not implementing. They found out of 100s of projects, that about two were 3 orders of magnitude larger, yet they delayed shipping those projects so they could get more in a release cycle, and diverted resources. From that new perspective, it was obvious that they should stop doing everything except those two projects. From the same talk, Microsoft found a third of projects were revenue negative! (Better to just not do them at all)

The point of the talk was ultimately that the revenue of projects usually dwarf the cost, to the extent that if a project is worth doing, it is clearly so whether it takes 3x or even 10x the time estimated.

[vp8989]

At the team level, keeping M to 1-2 works really well in my experience. Of course M is never really 1 or 2 because you're always wrapping up small details from $previous, looking ahead at $next or just doing $maintenance. A reasonably sized team will be kept busy enough with "just" an M of 1 or 2.

The constraint helps to ruthlessly focus on the most impactful work. The maximalists want to get cute and try to bin pack but it just doesn't work, unfortunately.