You say you "use retrospectsretrospectives." But what does the team actually do in these retrospectives? Since you've gone 18 months without once addressing this aspect of your process, I'm guessing the answer is: nothing very useful.
To me, the retrospective is the most important part of the process. Throw out or change anything else about scrum all you want (by mutual agreement of the team during a retrospective, of course), but commit to regularly taking the time to talk about how the process is working for everyone, share what worked and what didn't work, and propose ideas to improve. Keep trying to improve your process little-by-little every sprint, and sooner or later, you can have something that works pretty well.
In your case, that process doesn't seem to be working. Since sprint goals aren't being met, it's prudent that a retrospective focus on why this is the case. Obviously, the team took on too much work for the sprint. But why did they do that?
- Did they underestimate the complexity of the work?
- Did management pressure them to take on more work than the team thought it could handle?
- Did they have too many interruptions/emergencies that took resources away from completing the planned work?
- Did they experience bottlenecks that delayed completion of the work (say, waiting for assets from an external design team)?
- And even: were one or more team members incapable of doing the work at all?
These are the kind of questions the team should have been asking themselves every sprint for the past 18 months. Then, armed with the answers, they can propose suggested process improvements to trial for the next sprint. These might include:
- Take on less work in the next sprint (duh!)
- Be more conservative in estimates
- Tell whoever is pressuring us to do more work to sod off, as we're already taking on more than we can accomplish right now
- Manage interruptions better and adjust the amount of work in the next sprint to accommodate unavoidable emergencies
- Fix the bottlenecks or plan around the ones you can't avoid
- Don't assign stories to team members who cannot accomplish them (and separately, figure out the management response to address a situation with a poor-performing team member, from training and mentorship to dismissal)
This is the kind of conversation that should have happened every single sprint for the past 18 months. It's not about putting pressure on the team or adding more resources, but about using your retrospectives to improve your process on a continuous basis. That clearly isn't happening here.
You would think that by the 15th sprint with missed goals, the team would have discussed this in their retrospective so many times, to the point where they decided to just take on the most minimal sprint goals possible just for the sake of getting one complete. By the 25th uncompleted sprint, I'd just do a sprint with a single string change and nothing else. If the team can't manage that in a sprint, the problems are even worse than you let on.
To be clear, as several here have pointed out already, sprint goals are forecasts, not iron commitments, and missing goals is not itself indicative of anything other than making inaccurate forecasts. A great team can miss tons of goals because they're bad forecasters, while a awful team can meet every one and not deliver any actual value. But if your forecasts are wrong in the same direction for 18 months in a row, that part of your process is not working. Use your retrospectives to fix the process so your forecasts are reasonably close to the actual reality of what the team can deliver each sprint.