Velocity is a much-misunderstood concept and the purpose of this note is to help clarify what it is. Velocity is not mentioned in the Scrum Guide,  but we know that it plays an important role for most Scrum Teams to run effectively. We have six patterns that discuss velocity in a focused way:
Velocity also plays a strong supporting role in many other patterns, such as Release Plan, Kaizen Pulse and Teams that Finish Early Accelerate Faster. Velocity in itself is not a pattern (it doesn’t really build anything, but rather is a property of the Sprint and the team) and this note is here to help you understand the term as it is used in the patterns and to understand how it should be used with your teams.
A Development Team’s velocity is a (usually unit-less) number that indicates the team’s capacity to do work during a given Sprint. Velocity is intended to be a measure of the team’s efficiency: how much work the team completes per unit time, where Sprints are the units of time (e.g., two weeks).
Velocity it is not a measure of effort: the effort expended during a Sprint is constant because the Sprint duration is constant. It represents the total amount of work Done during a Sprint as a sum of the estimates that the team created for the Product Backlog Items (PBIs) at the beginning of the Sprint. Each of those estimates tells merely how much work is required to complete a given PBI relative to the amount of work for other PBIs (see Estimation Points). The velocity varies from Sprint to Sprint as a consequence of natural variance and of many factors affecting efficiency (loss of a team member, manufacturing equipment problems, variance in requirements quality, etc.)
The velocity is the Development Team’s number. The team derives the number from historic data, based on recent Sprints. When this number is used to postulate what the team will deliver in the Sprint, it is called the team’s forecast for the given Sprint. In the same sense that yesterday’s weather is a good predictor of today’s weather, so the performance in recent Sprints is a good indicator of what the team will achieve in the Sprint at hand. Velocity can be used as a forecast of work to be completed but not as a target or a guarantee. By analogy, if you forecast tomorrow’s weather as reaching 25°C and sunny, that isn’t the target for the weather, but only an informed guess of what the weather may be.
It is good practice to use recent history to inform the forecast for the upcoming Sprint: that is the essence of Yesterday’s Weather. At any given time the team’s velocity is a reasonable forecast of the team’s future performance based on an average of the team’s recent velocities. Because there is variance in any process, some Sprints will exhibit a higher-than-average velocity and some a lower-than-average velocity. When velocity is used to size the amount of work taken into a Sprint (the Sprint Backlog) — a recommended practice — then a Scrum Team should expect to finish all items on that backlog only 50% of the time. Note that the Scrum Team commits to the Sprint Goal and not their forecast velocity.
Velocity has a mean and a variance, and both are important to forecasting. A low variance on velocity makes forecasting more precise, and makes it possible to assess whether a given process change resulted in more work from the team in the Sprints where it was introduced. Teams can reduce their velocity’s variance through attentiveness to whole-team estimation and delivery, and by refusing to succumb to outside steering during the Production Episode.
Current broad practice bases velocity on the Development Team’s estimates rather than on either measured effort or measured results. In theory, we could somehow make the velocity more precise by re-estimating the actual amount of work (in relative units) each PBI took after the Sprint is over, and summing those estimates into a velocity. It’s rarely worth the trouble. Estimates tend to converge over time, and the pessimism for one estimate is usually offset by optimism for another. If the team is using Estimation Points, it’s impossible for the average to be overly optimistic or pessimistic because the time estimates are unitless. Feedback and Yesterday’s Weather (see above) drive both optimism and pessimism out of the forecast. In practice, teams find they can regularly use their velocity to predict what they will deliver in the upcoming Sprint with precision of plus or minus 20% or even much less.
Many teams measure velocity in terms of absolute time. However, most people can’t even tell you how many hours they “work” a day (work on actual PBIs) let alone tell how much time they spend on a given item. We recommend relative estimation instead — and velocity is hence unitless.
Other teams use sizing instead of estimation: for example, partitioning into tasks of equal size and using the number of Done tasks as the velocity. The conversion to the Product Backlog estimates is unclear.
Many managers we have worked with believe they can increase a team’s output by impressing on them the need to “work harder.” But lack of developer effort is rarely the problem. Velocity isn’t so much an indicator of how many coffee breaks the team is or isn’t taking, but rather about how smart and effectively the team is working. We want to put our focus on efficiency rather than brute force.
We offer these other guidelines for proper interpretation of velocity:
The term velocity started becoming au courant in the year 2000. This replaced load factor which was too complex, as discussed by Kent Beck, Don Wells and Robert C. Martin. 
 Jeff Sutherland and Ken Schwaber. “The Scrum Guide.” Scrumguides.org, http://www.scrumguides.org, July 2016 (accessed 19 June 2017).
 —. “Velocity vs [sic.] Load Factor.” C2.com, http://wiki.c2.com/?VelocityVsLoadFactor, 16 Feb. 2000 (accessed 19 June 2017).