With regards to completion rate, this is usually tracked as the team's velocity. Velocity is the number of story points that were completed in the time-boxed sprint. Because a story is either done or not done (there is no concept of a partially completed story), this works out to reveal the same information that your completion rate percentage would. Velocity from the previous sprints is used to determine the velocity of your next sprint.
The next factor is your load factor. If you are also tracking some unit of developer contribution to the sprint, you can base this on velocity. This is just a relationship between the amount (or percentage) of time in your sprint a given individual contributed to the project. This is in contrast to "overhead" time (training, non-project meetings) and "out of office" time (vacations, holidays, sick time), and time supporting other projects.
I think both concepts are best demonstrated with an example with numbers. If you have a development team that consists of 5 people who contributed 100% to a sprint that completed 20 story points, you can use this data for calculating the expected velocity of the next sprint. Normally, you would simply plan your next sprint to have a velocity of 20 story points. However, if you only have 4 developers that are going to give 100%, you are effectively at 80% of your previous sprint. Rather than planning on completing 20 story points, plan on completing 80% of 20 story points, or 16 story points.
Of course, there are some assumptions made here. The biggest assumption is that all people are equal. Different developers have different strengths and weaknesses, and you might not be able to say that 1 person from your development team actually contributes 20% of the effort. You'll need to figure out, using historical data and expert judgement, how best to handle these cases. But I believe the general methodology is sound for calculating a next sprint's velocity based on the velocity of the previous sprint along with the amount of time a developer is dedicating to the project.
As far as expected and usual velocity and load, don't base your data on other teams working other projects - there are too many variables in terms of capabilities, productivity, and so on. Base your first sprint on your team's historical data coupled with expert judgement (preferably in groups). You can also use cost and effort estimation tools if that makes you more comfortable, but I haven't encountered or read about too many agile teams using tools such as COCOMO or SLIM for effort/cost estimation. If you don't have any historical data from previous projects, the judgement of the team should prevail. Within a few sprints, your velocity and load should normalize, allowing you to effectively predict the next sprint using your newly-generated historical data.