Scrum does a few things.
First, it encourages prioritization. The supplier of work has to say what they want to be done first, and not say "everything is equally important".
Second, it generates somewhat usable product even if not everything is finished. That is the point of having a "potentially shipable product" at the end of each iteration.
Third, it gives a tighter feedback loop. By insisting that things be "done" at the end of a sprint, you avoid the "90% feature complete, but only half way done" problem; when pushing for deadlines, you can shove things that need to be done aside so it looks like you almost hit the deadline, or you can fake it. By having a definition of done, and insisting on things being done, you know if something is harder than it looks earlier instead of later.
Forth, it avoids inventory by moving detailed planning close to doing the work. Planning things far out is a form of inventory: capital spent on resources that isn't available for sale to or immediate use by customers. Such inventory can rot (plans change underfoot, new information makes it obsolete), misalign with needs (turns out we don't need a distributed network whatzit, because the thing using it wasn't worth it), and reduce value of shipped goods (if in the last year half of your time was spent on planning for next year and beyond, you could have gotten twice as much shipped if you instead worked on stuff to be ready for now). If you can move planning closer to execution without loss (tricky!), you can decrease inventory.
It isn't the only way to solve these problems. You seem to be using scrum where it provides a stream of work to developers to work on for each period of time, with periodically adding new work to do, and checking on progress.
This is a useful way to use scrum-esque patterns. It keeps work flowing, it keeps planning close to production, it provides some feedback loops, etc. It even has advantages in that it doesn't warp development and testing to match the system (if testing is best done with the work is basically finished, trying to get things finished and tested within the same sprint forces the back-end of the sprint to not involve new development!)
The failure to put exactly what they are going to do into a sprint it not evidence that your developers aren't doing great work. It means they aren't following SCRUM from on high, instead using parts of the framework.
If they had halved (or quartered) how much they committed to each sprint, but kept everything else the same, then they would have finished more than they had committed to each sprint! You would have the same amount of code produced. Clearly the "sprint failures" aren't the important part, because that is just an internal process detail. The goal of the company is to get shit done, and that shit be good; not to follow some specific process, unless your goal is a certain kind of ISO process certification.
The process exists subservient to the goal of the stuff done.
On the other hand, because they are not following the rules of SCRUM, you aren't getting the same kind of feedback. You should examine the resulting stuff to see if the kind of flaws produced are the flaws that SCRUM was designed to deal with; are there stories that live on like zombies forever, and only get killed way late? Are there stories that seem easy, they explode, and in a retrospective where not worth the total work? Is product actually shipable at the times you need/want to ship it?
