Velocity is the measure of work completed by the Delivery Team within each iteration. Often this is measured by the number of user Story Points a Delivery Team can complete in an Iteration.

Velocity does not relate to hours. So just do not compare them.

Velocity is NOT just about deployment or execution speed however. Human Element factors are also important. If onboarding a new Development Team member takes a month, or a quarter before they can deploy meaningful changes, that decreases Velocity as well. Splitting User Stories up into smaller services reduces the amount of information a new developer need in order to be effective. Pushing code quickly after joining a Delivery Team raises morale and helps identify gaps in the API Registry.

The Actual Velocity and involves dividing the total number of Story Points completed by the number of Iterations. For example, if the development team has completed a total of 70 points over two Iterations, the team's actual Velocity would be 35 points per Iteration.

The is expected Velocity, which involves dividing the total number of estimated Story Points by the number of Iterations. For example, if the development team estimates a total of 160 points over four sprints, the team's expected Velocity would be 40 per Iteration.

Velocity should only be used for the team for planning purposes. The success of the team should always be based upon the delivery of Business value--i.e. a working increment of the product delivered to the customer.

Velocity is also used within Iteration Planning to estimate how long it takes to deliver Business value, and forecasted in Story Points.

More Information#

There might be more information for this subject on one of the following: