Is this true? I was watching a talk from James Coplien the other day and he claimed 50%. That seems extreme.
https://www.linkedin.com/pulse/scrum-evening-james-coplien-v...
1) The task was not correctly estimated; it is discovered during the sprint that more effort than originally thought is needed.
2) Work that was not accounted for during sprint planning reduced your capacity; things like ad-hoc or unplanned meetings, sick time, peer and code reviews, HR processes, bugs from previous sprints, and so forth.
In both cases, the plan that came out of "sprint planning" does not match reality. I don't consider this to be a failure at all. How people react to it can be wrong, however. "Just get it done anyway", failing to inform team leads / managers when the change occurs, etc are unhealthy, because it creates a disconnect in expectations among the team due to either conflicting understanding of the work being done, or changes in expectations about capacity required.
So this isn't about failure at all: a failed Sprint is one that fails to meet the Sprint goal. I suggest taking a Scrum class to learn how velocity works, how agile works, and to learn how to manage uncertainty (and if you don't admit to this 50% uncertainty, then you are lying to yourself and cooking the books) and to learn about Sprint Goals.
Your post suggests that you understand none of these things. They are all Scrum basics.
This, so much. If you're missing sprint deadlines, its not necessarily a personal failure as much as a process failure. The solution is to commit to less, to refine your items of work so they can possibly be met in the time you expect. For this to work though, there has to be buy-in from the team members: you can't force it on them.
I've also found that the somewhat artificial sprint goals do act as a good motivation for the team to help each other if they see that the goals might be missed.
There's also the part where you have to be continuously getting feedback and tweaking the ways in which you run the process based on the feedback. If team members feel that this is just another unresponsive management tool designed to get them to work more, it will fail miserably. Instead, if they see it as a construct to provide accountability to stakeholders, they will strive to change and improve the process until it works well.
Ultimately though, the key feature seems to be: the people. If you're not working with a team that's genuinely interested in accountability and helping the product succeed, this process will not work. These are high-trust, highly nimble processes which are completely inefficient if they are actively sabotaged or the promises of good-faith expectations are violated.