I noticed in scrum meetings, that developers often give realistic estimations on stories. However, even rather simple stories need a lot efforts for configuration, setting up third party components, testing and final build, and the system has accumulated quite some technical debt, so the estimates often appear too high for the product owner or management.
The PO frequently tries to beat down such estimates, like: "What, you want 13 story points [4 days] for this story, this can't be! I can't explain this to management, somebody should be able to code this with 3 SP [in 4 hours]!". As a result, the developers get their arms twisted to commit to a 5 or 8 story points [1.5 to 2 days] estimate (Scrum estimates are still taken as commitments, not just forecasts).
Of course, without any plan to strip down expectations (mainly on testing and quality), these sprints frequently fail. The estimate of the developers is a honest, realistic one, and beating down the estimate does not beat down the actual work to be done.
One can say: "You should not make an impossible commitment, just because somebody pushes you to do!" But in my opinion, the job of a developer is software design and coding, not bargaining or standing up against pressure! There may be jacks of all trades, typically those dealing directly with external customers, but this is not the majority of office developers!
To me, this practice just makes programmers look like jerks, causes constant sprint failures and prevents realistic estimations, as well as looking for actual improvements.
What do the Scrum guidelines say on this topic, or do they say anything on it?
EDIT: replaced times by story points. I was referring to the initial estimation phase with Planning Poker and story points, not the task detail planning. I just put the days/hours there, because it was a typical dialogue like this sometimes, also with time instead of points. Sorry for any confusion! The story point examples represent longer time periods than the time examples.
EDIT 2 There is currently no dedicated scrum master, and the PO takes that role, when it comes to estimation meetings. So it's probably the role conflict making this inappropriate bargaining worse, since he appears as an authority, instead of a neutral or developer scrum master. Perhaps, this can be fixed by taking him as a biased participant instead of a "master", as long as none is available.