I think you're getting stuck in the math too much, and losing sight of what's important.
The reason you do all of this stuff is to figure out how much work the team should put into a Sprint and commit to. When you're confident that you have a handle on this, then you can start to meaningfully extrapolate how many Sprints it should take to get a certain way down the PB, although even this gets dicey because the PB is a living evolving thing.
What you really want to do is figure out how many estimated man days, or man hours, or story points, or fable pennies or whatever unit you want to use, that you can get done in a Sprint. Nothing else matters. You can call that velocity if you want, or make up your own term that works better for you.
The real issue that you have is to figure out what happened with your estimates on the last Sprint. Why were they off by so much? Now that is going to lead you to one of a few conclusions:
- It was a one-off fluke and probably will never happen again. Discard the results and continue on like it didn't happen.
- Damn! We suck at estimating and we habitually over-estimate each task. It will never change. So double the amount of estimated work you put into each Sprint.
- We're consistently over-estimating our work by a factor of two, so we'll halve every estimate going forward and leave our estimated velocity the same.
- Damn! We suck at estimating and we're going to improve. IMHO, this is the best conclusion but also the one that gives you the most planning problems. Why? Because your estimates are going to constantly improve in accuracy and your velocity is a measure of your past ability to complete estimated tasks. So your past velocity is only partially relevant to the velocity you'll expect to have in the future as your estimating techniques improve.
When we started doing Scrum 8 years ago, I routinely calculated the number of man days available to Sprint project work by taking the total number of man days that the team members were in the office and dividing by two. That drove my boss crazy, because he wanted to know why we were giving up half a day for each work day without a fight. I figured it was aggressive because I thought I'd be lucky if I ever got any near to 1/2 a day on project work from each team member each day.
So essentially, I just randomly assigned a focus factor of 50%, even though I'd never heard of the term "focus factor". And that was good enough to get Sprints up and running at the beginning of our Scrum experience. Over time, I've learned that we'll do well if we take on between 8 and 11 days of project work for each team member for each 4 week Sprint. I'll adjust that down if someone is on vacation or out of the office for a few days, or if we know that there's something going on with the business that's likely to take one of the team members away from the project for a while.
Our team is not homogeneous in skill sets (yet!), so we actually carve up the tasks to individual members or groups of members during the planning meeting. Then we add up all of the man days for each team member. If I see a 13, or if I see a whole bunch of 11's on the whiteboard then I know we've got a problem. We'll shuffle stuff around if possible, or drop stuff out of the Sprint.
But the point is, there's no math involved. I keep an eye on whether or not everything got done, and whether there was extra time left over for someone, and then we discuss it and adjust as necessary when going forward. It doesn't need to be complicated. You want to keep the project moving forward as fast as possible, but not overloading the Sprints so that stuff doesn't get completed.