In Scrum it is considered a good idea for a self-managing Development Team to know about the progress it has been making:
The input to this meeting (note: Sprint Planning) is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. (Source: The Scrum Guide)
Teams express this ‘past performance’ often as ‘Velocity‘. Although not mandatory, it is a good tactic to apply in Scrum.
Velocity: an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team. (source: the Scrum Glossary)
Many organisations adopt Scrum to be more agile, to increase their agility. Agility with Scrum is achieved through the creation and frequent release of Increments of software.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (source: Principles of Agile Software Development)
In the face of the purpose of increased agility through Scrum, the best definition of Velocity in Scrum actually is a measure of a team’s ability to produce releasable software in a Sprint. Having no releasable software by the end of a Sprint is… zero velocity.
Working software is the primary measure of progress. (source: Principles of Agile Software Development)
In the face of the purpose of increased agility through Scrum, it doesn’t add much value to discuss Velocity when no releasable software is created throughout a Sprint. There are probably more serious problems to resolve first. Discussing the standardization, normalization, industrialization, equalization of Velocity is futile, at best highly sub-optimal, in the face of striving for agility with Scrum. In the absence of the capability to produce releasable software every 1-4 weeks, such discussions do no more than distract from more serious problems to solve first.
You can obviously measure the Velocity of creating undone software, and be more predictable in making progress creating undone software. Keep in mind that it may be an obfuscating indicator, not a measurement that increases transparency.
Velocity in Scrum actually is an indicator of productivity, an indicator of how much software, preferably releasable software, a team has produced in a Sprint. That in turn is not a promise, nor a contract for the future. Predictions are fragile. Empirical process control has the potential of antifragility. We embrace complexity.
In complex environments, what will happen is unknown. (Source: The Scrum Guide)
In Scrum, actually… velocity makes most sense if a measure of a team’s capability to create releasable software.