This is an excellent question and is very important for teams to improve. The topic is deceptive and is widely misunderstood.
The original purpose of story pointing was to find a quick and acceptably accurate method of estimating the Level of Effort (LOE) needed to complete functionality that was defined in stories. The overall objective: give teams a method of FORECASTING or predicting how long it would take to complete an effort (such as a project).
Your understanding of Velocity is right: it is the AVERAGE points per Sprint completed (truly DONE). So if you have a project to deliver, and it is 250 points, and your team averages 25 points per sprint, the project will take roughly 10 sprints, plus or minus some buffer time.
Some luminaries, such as Ken Schwaber, suggest that velocity and points only be used for mid- to long-term forecasting. They suggest using task hours as a second "sanity check" on what can actually be done in a sprint. So the amount of points in each sprint may vary depending on capacity.
Others (including myself), believe that a mature team will settle into a very consistent sizing pattern that can accurately predict capacity, and eventually task hours become a useless additional burden. (It is critical to perform for new teams for at least 6 to 12 sprints, IMHO, until the team's understanding of points and story sizing is accurate.)
Your first little error is that you said the team should know velocity and bring in that many story points. Actually, coaches encourage teams to deduct 10% to 20% and commit* to that level instead. So if your team tends to complete 25 points per sprint, don't fill up the sprint to 25 points, but rather, stop at 20 to 22 points.
Remember: it is perfectly FINE to bring in stories when the other work is done. So you might "commit" to 22 points and complete 28. That is great.
Just be careful to not encourage the team to "sandbag" and constantly under commit. There's nothing wrong with stretching to see if we can do more.
Now, to your point about the variance between sprints. It is a very common (but NOT OPTIMAL) pattern to see a team that completes 20 points one sprint, then 50, then 22, then 45, then 15, then 60.
If you calculate the deviation, it may show swings of 50% to 100% sprint after sprint.
Why do teams complete just 15 points in one sprint, and then 60 in the next?
It might mean that the team really doesn't know what they can get done. (Hey, we completed 50 points last sprint, we can do it again this sprint).
OR, it might indicate that product owners are forcing the team to over commit, or are adding work after the sprint start, etc. These are just some of the ANTI-PATTERNS that could be causing this wild swing in completed points.
This Predictability measure is an important one for scrum masters to observe and bring to the team's attention.
Often, the reason they completed few points in one sprint, and then many points in the next sprint is what I call the "ROLLING WAVE OF INCOMPLETE WORK".
Here is a very common pattern:
The product owner is under pressure to meet a date. So the team feels the need to try to get a lot of work done. They start out as a new team, and aren't sure what they can actually get done.
So sprint 1, they plan the sprint and as they are in Forming phase, can't complete all the work. In fact, they have more incomplete work than done work. The incomplete work is STARTED but INCOMPLETE. It is moved to the next sprint, and this time they have more done work than incomplete. By the next sprint, that large load of incomplete work drops into DONE and the team's confidence soars.
The product owner is excited and so they increase their load again.
At the end of this sprint, they have a HUGE amount of incomplete work, and a disappointing amount of DONE work.
Here you begin to see the WAVES of Done vs Incomplete alternating sprint after sprint. If teams don't realize what is happening, this pattern can continue for months. But on average, they complete around 24 points per sprint.
So what happens when they quit over-committing?
You'll note that they STILL complete 24 to 26 points, but the carry-over work is reduced. Now, instead of being overwhelmed trying to complete an impossible amount of work, which also destroys team morale, the team can begin to improve their processes.
Over time, velocity will begin to increase, without the huge swings in Done-vs-Incomplete work.
If you don't allow the team some "slack time", they will NEVER have time to perform work that will make them leaner, faster, better. Dev-Ops, for example, can't happen. Test Automation--Who has the time for that!?
But these are precisely the things that teams need to work on so they can increase velocity.