Velocity is a measure of work the Team performs during a single Sprint and is measured at Sprints end by calculating the Points of completed User Stories. Knowing velocity, the team can compute an estimate of how long the project will take to complete.
Velocity is a term in Agile product development
Velocity is a term in Agile product development disciplines and is increasingly used today not only by Scrum teams but also by Project Management and Product Management roles.
It's easy to understand the concept, and at the same time, it's а simple idea. Velocity is the "speed" at which teams complete planned tasks.
Velocity needs a fixed period
To be able to measure the "velocity" of a team, some agreed period should be set for active work. This period could be your Sprint.
Calculating Team Velocity
During a Sprint, the entire team completes tasks or User Stories. At the end of the Sprint (a week or two weeks, or any other designated period), the team completed, for example, 10 User Stories (Product Backlog Items).
Each of these 10 tasks, User Stories or Product Backlog items, had specific Story Points. Some Product Backlog item was rated 3 Story Points. Another was rated 8. Some could be 1 or 21.
If we add up the total of these completed 10 items during the Sprint, we get some numbers. For example, 133.
133 is the Velocity value of the team.
What can we use Velocity for?
Planning Sprint work
After we have calculated the Velocity of the team, it can be easier to predict how many tasks or Product Backlog items can be completed by the Development team in the next period (Sprint).
If 133 was the Team Velocity of the past Sprint, the list of planned Product Backlog items (or User Stories) is opened, and the Story Points written for each item are considered.
You start counting the Story Points values of the next waiting and planned items, adding up the Story Points values. When you reach a total points of about 133, you can count on the fact that those planned Product Backlog Items, which have a total of 133 relative time, will be successfully developed by the team during the next Sprint.
Suppose the Development team consists of 5 participants. All these 5 participants together have completed 133 points of work.
If you divide 133 work points into 5 participants, you will receive 26.6. Let's round this number to 27. So we can roughly say that one member of the Development team finishes 27 points in one Sprint.
Business stakeholder and Team Velocity
If a director or business stakeholder asks you to accelerate project work by increasing the size of the team, you may assume the following:
If you add another specialist to the team, the points for the next Sprint, instead of 133, will already be 133 + 27 = 160. Then you can hope that for one sprint, the team will complete 160 points of work. Thus, instead of a total of 10 items, these 160 points may include, for example, 15 items. Your business stakeholders will enjoy faster development.
If one participant leaves the team, you simply subtract 27 from 133 to get 106. The team can produce such work points during the next period (Sprint) if you are left without one participant.
Once you have the team velocity measured in points, you can theoretically calculate an unlimited number of Product Backlog Items in the future and determine how many Sprints (periods, weeks, months, etc.) will be required to complete all items.
Relativity and Velocity
Some important topics to keep in mind about the Velocity:
The further in time you plan, the more inaccurate your estimates will be.
The longer the team works together, the more work (Story) points they can develop over a period.
If you add a new member to the team, keep in mind that the team needs to unite again before you can predict with greater accuracy the Velocity of your team.
If one participant leaves the team, this does not mean that a certain number of points must be subtracted from the total Velocity. This participant may have worked with the largest or smallest capacity.
Everything is relative.
If you change your technology and tools, Velocity will temporarily decline as teams gain substantial experience with new resources and speed up again.
Various factors in a project or organization can affect Velocity's value.