What always annoyed me about Story Points is that it's a measure of complexity, not time. At least that's what Story Points are supposed to stand for.
When you state that a team should know how many Story Points it can handle, it would make much more sense to see Story Points as some measure of time. If you've completed last few Sprints 38 to 42 Story Points, with 2 full-time devs, than one could state that a single developer on average can finish 20 Story Points in Sprint. And if a Sprint is 2 weeks (10 days), that would mean maybe 2 Story Points per day for each dev.
Yet, in every business environment I've been in, the SCRUM fanatics always state that "No, story points are a measure of complexity". In practice, to me, this makes no sense. At least not if one wants to use historic Story Points to estimate how much work can be completed in the next Sprint.
The problem is that time isn't something you can chop up neatly.
For ease of use, let's say that a story point represents 8 hours of actual work. That gives us 168/8 points a week, or 21 points. Of course, we lose 7 of those to sleep, 4 to the weekend and another 5 to the evenings during the week, leaving us with 5 points per week. You probably lose a point to lunch, coffee, bathroom breaks and mingling with coworkers and another point to meetings and interruptions.
That leaves you with 3 points out of 21 potential points in a week, and you aren't getting 3/5 done per day. Using story points instead of hours tries to get people to treat the sprint as a unit instead of time as a unit, since time can be split up to a very fine degree. Just because you work 40 hours a week doesn't mean you can complete 20 2 hour tasks.
I'm not that dogmatic. But complexity should loosely correspond to time, I would think. A deeply complex task is going to entail more work than a simple one.
That said, there's a good reason to say it measures the complexity, and not the time. You want to keep distance between your estimates and time, or else the business people are likely to come to you and say "You said this will take 6 hours, so I expect it tomorrow". Nevermind that it requires another task to be done first, that it's blocked on getting something from another department, that you only ever committed to delivering it at the end of the sprint, and that you underestimated how long it would take anyway (but it doesn't matter because you overestimated something else so it comes out in the wash), -you- said it would only take 6 hours!
When you state that a team should know how many Story Points it can handle, it would make much more sense to see Story Points as some measure of time. If you've completed last few Sprints 38 to 42 Story Points, with 2 full-time devs, than one could state that a single developer on average can finish 20 Story Points in Sprint. And if a Sprint is 2 weeks (10 days), that would mean maybe 2 Story Points per day for each dev.
Yet, in every business environment I've been in, the SCRUM fanatics always state that "No, story points are a measure of complexity". In practice, to me, this makes no sense. At least not if one wants to use historic Story Points to estimate how much work can be completed in the next Sprint.