There are already several excellent answers. In particular, bad estimation, over-commitment, and/or unscheduled work are frequent causes of slippage.

But I'm curious as to why "[your] developers choose the features they want to include in each sprint". The developers should typically be working on the features with the highest priority first -- and priority is a business decision, i.e. that should be coming from the product owner acting as a proxy for the business stakeholders.
(There are exceptions to this. In particular, it's generally preferable to work high-risk features earlier. And in some cases a user-facing feature may depend on other functionality, e.g. "we really need to add a database to do this right".)

On the other hand, estimates are technical decisions, and should not be made (or second-guessed) by business people. You don't say anything about this -- I raise the point only because, in my experience, when developers are choosing what to work on, it's fairly common for the business people to try to dictate how long it should take.

It sounds like you have a fairly dysfunctional process. I would recommend against bringing in developer consultants, at for the time being, because that is probably going to have a negative effect on morale. But it sounds like your organization could use some help on the project management side. That's where I would start, by bringing in an experienced agile coach -- if not for a medium to long-term engagement, then at least for an assessment or "health check". A good coach will tell you if you have underperforming developers, but at least this way, it's the entire team (not just the devs) who are under scrutiny.

One other observation: in my experience it's very difficult to make scrum succeed as a project management methodology if you're not also following good development processes. Are you doing automated unit testing? or even better, automated acceptance testing? Are your devs pairing, or do you at least perform frequent code reviews and/or walkthroughs? Are you practicing some form of continuous integration?

There are already several excellent answers. In particular, bad estimation, over-commitment, and/or unscheduled work are frequent causes of slippage.

But I'm curious as to why "[your] developers choose the features they want to include in each sprint". The developers should typically be working on the features with the highest priority first -- and priority is a business decision, i.e. that should be coming from the product owner acting as a proxy for the business stakeholders.
(There are exceptions to this. In particular, high-risk features are generally worked earlier. And in some cases a user-facing feature may depend on other functionality, e.g. "we really need to add a database before we can implement X".)

On the other hand, estimates are technical decisions, and should not be made (or second-guessed) by business people. You don't say anything about this -- I raise the point only because, in my experience, when developers are choosing what to work on, it's fairly common for the business people to try to dictate how long it should take.

It sounds like you have a fairly dysfunctional process. I would recommend against bringing in developer consultants, at least for the time being, because that is probably going to have a negative effect on morale. But it sounds like your organization could use some help on the project management side. That's where I would start, by bringing in an experienced agile coach -- if not for a medium to long-term engagement, then at least for an assessment or "health check". A good coach will tell you if you have underperforming developers, but at least this way, it's the entire team (not just the devs) who are under scrutiny.

One other observation: in my experience it's very difficult to make scrum succeed as a project management methodology if you're not also following good development processes. Are you doing automated unit testing? or even better, automated acceptance testing? Are your devs pairing, or do you at least perform frequent code reviews and/or walkthroughs? Are you practicing some form of continuous integration?