If a task cannot be completed within the timeline of a sprint, one of two things are true:
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.
The 50% is simple math. If your velocity is V, you take V estimation points of work into the Sprint. V is a stochastic variable with a mean and a variance. You rarely deliver exactly V points: it is just the mean. About half the Sprints finish early, and about half the Sprints don't deliver everything on the Sprint backlog.
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.
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...