Sprint Planning

During sprint planning, the team selects user stories from the backlog and estimate effort for the upcoming sprint. If you are finding that your team is not completing all of its user stories each sprint, you might want to start looking at your user stories and how you are selecting them during sprint planning as well as whether scheduling issues that may or may not have been known when the sprint started.

First, in regards to the stories themselves, are there issues that could have been addressed during sprint planning (or even in backlog grooming)? Things such as:

Does the team have a clear understanding of the each story and its related acceptance criteria?

Make sure that the team is asking questions about the acceptance criteria, if they are not clear. The product owner can provide information. Without a clear understanding of the acceptance criteria, the team increases the odds of producing components that cannot be included in the product.
Are there known issues that had the potential to block development that are not being raised during sprint planning?

Sprint planning is a collaborative effort, where discussion of issues is expected. If user stories are being planned for the sprint, but those stories are going to be blocked by other issues, this should be raised during sprint planning. The team should not assume that everyone is aware of blocking issues. The team can then discuss if they can continue with this user story and how the blocking issue can be addressed.
Are you bringing in stories to be sized during sprint planning that are not well understood and/or sized correctly?

Although ideally user stories are sized and prioritized during backlog grooming, the team needs to be able to bring in stories during sprint planning to deal with changing priorities and/or to deal with product issues. If your team is having problems completing these reprioritized stories during the sprint, this might indicate that you are not be spending enough time understanding these stories so that you can size them appropriately. Encourage your team to ask questions during sprint planning until they understand the stories and the acceptance criteria.

Second, in regards to scheduling, did you consider all aspects of the team’s scheduled when you planned the sprint?

Are you considering holidays and vacation time when planning your sprints, or is your team experiencing a higher than usual absence rate due to illness?

Make sure that you are accounting for company holidays and that your team members are communicating about their scheduled time off. Although your team’s velocity will reflect the reduction in work, this is expected. The team does not work the same number of hours every week. You have to match the workload of the team to the number of hours that they are working. As for unplanned time off (due to illness, etc.), you cannot do much to account for this. However, you should at least be aware that unplanned illnesses may impact you work schedule. You can choose to allocate resources at 80% to account for occasional unplanned absences or for work that is not directly related to their user stories.
Are tasks being assigned to a particular engineer, because they are the expert in that area, even though that person is already fully committed to the sprint?

Although it is perfectly natural to have an expert on your team for any given technology or feature, you have to try to develop the expertise in your team so that you do not have a single point of failure. This may take time. Your velocity might take a hit if other members of your team take longer to finish a task than your expert, but in the long run, your team will run more efficiently.
Are you taking into consideration that some of your team members are not fully dedicated to the project and must spend time on other projects outside of this scrum team?

In some cases, team members are part of multiple scrum teams or have obligations outside of your scrum team. The time that they have available in any given sprint might vary, so be aware of this during sprint planning. Do not overcommit them to work. If they only have 50% of their time available to work on your project, make sure that their assigned tasks do not require the same as a team member that is allocated to your team 100%.