[yurishimo]

Honest question: why is this bad?

If my estimates are padded to the point where I always complete what I commit to and my boss is happy with my output, what’s the problem? My boss gets value from being able to accurately convey estimates to clients, the client 9/10 gets the work done on time or maybe even gets a couple extra features completed in the same timeline, and I as the engineer, have a relaxed work environment, free of the stress of cramming every story point possible into 40 hours a week.

Seems like a win win win to me.

[sahila]

This might be okay in isolation, but eventually as the entire team of engineers start to underdeliver, the team and company does get affected in terms of feature rollouts / velocity, and it's difficult to recover from it. People won't want to suddenly correct / do more work even if it's crucial, and they can point to their previous underestimated commitments and say that is a full week's worth of work. YMMV as with anything, but not knowing a team's true velocity does affect planning and sales.

[rglullis]

Parent said "boss is happy with output", there is no underdelivering here.

[solardev]

The actual work doesn't change, it just changes your point estimations. Either the boss is happy with the actual pace and quality of the work, in which case you don't need points to begin with, or the boss doesn't understand the difference between story points and actual time, in which case it's all a dog and pony show anyway.

All this teaches employees is to lie to make themselves look good. If you really want to increase development velocity, implement better coding practices and devops and tooling and training and invest in your employees instead of making jump through stupid hoops like circus animals.