It’s easy to get confused or overly concerned about measuring velocity. Actually, the concept is almost embarrassingly simple. Velocity in Agile is simply the number of units of work completed in a certain interval. Like in many fields, Agile proponents appropriated existing terminology.
Here is one typical definition, from agilesoftwaredevelopment.com:
In Scrum, Velocity is how much product backlog effort a team can handle in one Sprint. Velocity is usually measured in story points or ideal days per Sprint… This way, if the team delivered software for 30 story points in the last Sprint their Velocity is 30.
Velocity as a capacity planning tool used in Agile software development is calculated from the results of several completed sprints. This velocity is then used in planning future sprints.
The concept of velocity comes from physics. In physics, velocity is speed and direction, in other words, the rate of change of position of an object. Speed can be measured in many different ways.
In software, speed is frequently measured as size per unit of time (sometimes this has been called delivery rate). The measure of size could be any of the common size measures: lines of code, function points, requirements, changes, use cases, story points. The measure of time could be calendar time (month, week, day) or it could be specific to a project (sprint, release). As to direction, in software hopefully the direction is positive, but sometimes projects go backwards (for example, backing functionality out of a system).
The measure of size selected depends on data availability and the objectives of the analysis. Story points per sprint is useful for velocity for a given team for their recent history and planning the near future. Story points are less useful when estimating farther into the future or for a combination of teams.
Wouldn’t it be great if there was one standard size measure that everyone used for velocity? Unfortunately, no. Metric selection depends on the intended use. In a blog post about the concept of Single Version of the Truth, I explained that even with a common data source, making good decisions still depends on choosing and understanding the appropriate analysis.
In sum, velocity is simply work divided by time. In agile, work is frequently measured in story points. However, story points are project and team specific, and are not directly comparable to other projects. Nor are they available far in advance of the start of a sprint. Therefore, we often use other size measures, depending on what is available at the time the analysis is being completed.