That can only work for a short time. There is a feedback loop at play here and it will seek a stable equilibrium. The organization needs to solve its internal p

That can only work for a short time. There is a feedback loop at play here and it will seek a stable equilibrium. The organization needs to solve its internal problem. The move from estimates to story points is actually a part of this compensation already, companies pretend that story points are about giving the developers more freedom to our faces, but actually they are about taking our estimate that something can be done in a week and removing the word “week” so that it can be estimated as a couple days’ work instead by our supervisors. The fundamental process is already, at most agile shops I have seen, - I the dev am going to build in some unconscious safety buffer by giving an estimate that I'm 90% or 95% confident in, - I am going to give myself more safety buffer consciously by doubling or tripling that estimate when I communicate it to my boss, - my boss is going to give us even more safety buffer by lumping together all of our tasks and then adding another 50% of time to that - and then they are going to give it to their non-technical bosses, who are going to survey this estimate for the project and insist that it needs to be done in 25% less time, it is urgent, we need it sooner than that. Story points allow a bunch of this to happen without explicitly contradicting anyone. But the basic problems is much more fundamental and it is that management and engineering are being phrased as having opposed interests. This is a basic failure in any negotiation: once it turns into a zero-sum game, everybody loses. In turn, there is a set of books that pinpoint say deeper problem, as being focused on controlling costs rather than driving revenues—which we see in these story point quotas, gotta make sure you get your money's worth from the dev team.