Written by Velocity can be termed as the run rate of the team . Agile teams use this metric to measure how much work was done in a sprint so that we know how much more is left to actually make the reason.
Let take a simple example.
The team has ten stories whose total story point is 140. They pulled around 30 points of work this sprint. They finished 25 points. This 25 is their run rate.
With this the team and product owner can project how many more sprints are needed to finish the work.
We are assuming that the team is using story points here.
Some myths about velocity
1. Teams velocity keeps increasing over time.
2. A team having a better run rate is a better team
3. Since some team last year delivered at a certain velocity, this new team will also deliver at the same velocity
4 Velocity can be a predictable measure sprint after sprint even if we keep moving team members in and out.
I have seen many team members mindlessly argue over the effectiveness of velocity and end up wasting valuable time.
In fact in the beginning in 2005, as a developer, I would not see the point of such calculations. After a while, I got used to this and stopped worrying about such metrics and just focused on writing clean code.
Also, velocity as a measure only works well with teams that tend to practice Scrum and not as much with Kanban or XP teams.
Many scrum masters get into this coach mode with a single focus to help increase the velocity of the team. Instead, I would encourage ScrumMasters to look at completing the work they pulled min style, as well as help team and team members, identify waste in the system.
This metric is not as important as a number of automated unit test or number of production bug in the system.
Agile Practitioners Guide 
In general human tendency, everybody like to have some budgeting and feature achievement goals. I am working in SCRUM mode and customer is also well trained by Agile gurus but still he keeps pressuring for velocity and goals achievement for release. Similar experience in other projects of my colleagues. Clients have even gone to the extent that define hrs per story point and then define story points while grooming.
On other thought the management asks for increasing productivity. Then how to measure productivity which is not subjective? Line of code is not relevant any more.
So in real word due to cost pressure people are tend to look for such sizing and measurement in any mode of development.