How to ensure that Scrum team is not over committing to the Sprint.

The idea of committing to a Sprint Backlog was removed in the July 2011 edition of The Scrum Guide and was replaced with the idea of forecasting. In Scrum Guide terminology, the Scrum Team no longer commits to delivering a body of work at the end of a Sprint. Instead, they forecast the amount of work that they believe they can finish in the Sprint and work with the Product Owner to craft a Sprint Goal, which describes why the team is building the things that it is building.

Now, the fact that the Sprint Backlog is routinely left with undone items at the end of the Sprint may raise some questions:

• Is the team meeting their Sprint Goals?
• Is the business making external commitments based on the team's Sprint Backlog? If so, does the team understand this?
• What is the impact of the team regularly not delivering some items in the Sprint?
• Are the items that are being completed being done with the necessary level of quality?

Tell us a bit more as to what is happening to cause the 80% incompletion.  What insights were generated by the team in the Sprint Review as to why they are so far off in Sprint Planning?    

Does your team have a Sprint Goal each Sprint?  I encourage teams to commit to the Sprint Goal, an outcome, not story points.  The Sprint Goal will give your team focus.

Is there any structure or process to ensure that the team is able to commit the no. of story points to its capacity in Sprint planning?

Why do that at all? Story pointing is just a technique for helping teams to decide how much work they can take on. What use are story points to a Product Owner and his or her stakeholders? Why expect a commitment based on points? Why aren’t they more interested in getting usable increments which yield valuable outcomes?

If value isn’t actually being delivered, then that is the problem which ought to be addressed. Using story points as some sort of proxy for value and/or commitment will just lead the team off into the weeds.

The "velocity answer". 

Story points are a guess based on the information that they know at the time they make the guess.  If you want to know why they aren't completing all of their points, ask the team why.  It could be that they are learning new information while working on the stories which implies that they could do a better job of refining the stories.  It could be that they just haven't determined how much work they can consistently do. 

My real answer

Yeah, so what?  Story points are guesses based on the information that they know at the time that they make the guess that is used to help the team gauge the complexity of work needed to complete the story.  The real thing you should be concerned about is whether the team is delivering the value that they forecast to deliver.  Are they consistently delivering potentially releasable increments?  Are they meeting the Sprint Goals that the entire Scrum Team sets?

Your Scrum Team needs to identify ways that will measure their ability to deliver value.  Trying to meet a value based on guesses is not a good way to do that.  Does the stakeholder really care that you completed 24 points if they get nothing of value?  Is the team high performing if they consistently complete 24 points and never deliver any value?