"The PMO has created a performance report for all Agile projects in the organization. Your team is among the bottom 20 percent in terms of velocity. It clearly states that your team is underperforming."
"Your team's velocity is only 42 with 10 resources? Look at Andy -- his team's velocity is 160 with only 7 resources."
The two examples above give an interesting overview of how velocity can be used and misused: used -- as in how different people use velocity in different ways -- and misused -- what they are going to do with it, once they have used it in their own ways.
Velocity in simple terms can be defined as, "The amount of work your team is capable of completing in a sprint." You can calculate the sum of story points completed by a team in a sprint and consider it as velocity for that sprint. Calculate velocity for next two sprints and take the average velocity of first three sprints. This average velocity is your team's velocity.
If you know the velocity of your team, you can:
Predict the date for the next release.
Predict when all features from the backlog will be implemented.
Look at the team's trend for an indication of whether it is getting slower or faster.
Velocity is not a metric to:
Story points versus hours
Use as a stick and beat your team.
Compare two teams to find the better-performing team
Draw conclusions such as, "The average velocity of our organization is 450!! We are the best in the industry!"
One big dilemma faced by traditional project managers in Scrum is how to convert story points into hours. Over the years, they have learned and practiced using "hour" as a unit of estimation. It may become very difficult for them to understand "story points/velocity," and they end up defining new rules and processes on top of Scrum that defeat the core values of Scrum.
Instead of defining a relation between story points and hours, it will be good to understand that estimating story points and hours for tasks fulfills two different purposes. One gives you an indication about complexity and other gives you the time you will spend for completing that task.
Personally, I don't see using hours as a unit for estimation to be a good practice. Hours may vary drastically depending upon expertise of resource, past experience with the same piece of code, etc. What's more important is how much value your team is delivering to the business. You will be surprised to see the amount of value your team members can produce when you don't put a sword over their necks.