Velocity – An Agile Metrics

Agile ways of working prioritize delivering value to customers through continuous improvement, collaboration, and iterative development. In this context, velocity is crucial for measuring team progress and speed. It indicates how much work a team can complete within a specific timeframe. However, misusing velocity can be risky and counterproductive. In this article, we will delve into what velocity is, how it is used, and the potential pitfalls that come with it. We will also explore the good usage of velocity to improve planning accuracy and delivery rate predictability. Our topics of discussion include:

What is Velocity

Usages of Velocity

• Release Planning
• Feedback on Delivery Rate Predictability
• Using Velocity Metrics to Improve Planning Accuracy
• Velocity and Capacity Ratio

Risky Usages of Velocity in Agile

• Velocity as a Team Comparison Metric
• Agile Velocity as a Performance Metric
• Expecting Growth by Some Percentage

What is Velocity

Velocity is a crucial metric in Agile working methods that measures the work rate. It comprises two essential elements – the amount of work completed and the work period. The work period component is relatively straightforward as Agile teams focus on completing work in fixed-duration iterations or sprints. Therefore, agile velocity represents the work completed in a given sprint.
However, quantifying the amount of work completed can be challenging, particularly in knowledge-based industries. Agile teams use story point estimation to gauge the size of work items, also known as stories. The team assigns a size to each story based on collective judgment, which serves as a representation of its size. This size can be used to determine the work done number in a given sprint or iteration. At the end of each iteration/sprint, the team sums up the story point estimates of completed user stories (as per the Definition of Done) to calculate the velocity for that Iteration / Sprint. For instance, if the team completed three stories with sizes of 3, 5, and 8 story points, the velocity for that iteration would be 3+5+8 = 16.

Sprint Velocity = Sum of Story Points of Done Stories

Usages of Velocity

Release Planning

Velocity plays a significant role in Agile approaches for long-term delivery planning, known as release planning. In Agile, we avoid analyzing identified requirements in detail due to the expected high variability and the discovery of more technical approaches and requirements in each iteration. However, for sharing milestones with stakeholders, estimating the work items without breaking them down into activities is essential. Story point estimation is a higher-level judgment applied to estimate work items at the story level without getting into the details of identified items.
Velocity is a critical metric in release planning, as it helps identify how much work the team can complete in each iteration/sprint in terms of story points. By estimating the backlog items in story points, we can use the team’s velocity number to determine how many iterations/sprints it will take to deliver a specific number of work items.
For instance, if we need to plan the release of ten work items, we can estimate their size in story points and divide them by the team’s estimated or historic average velocity. This calculation will give us an idea of the number of iterations/sprints required to complete the work. Therefore, velocity is a valuable tool for release planning, enabling Agile teams to estimate work items at a higher level without getting into the details of each identified item.

Feedback on Delivery Rate Predictability

Velocity is a crucial feedback mechanism for monitoring delivery rate. While it is expected to fluctuate from sprint to sprint, there is an identifiable range for a mature team. By analyzing historical data from the last 5 to 6 sprints, a team can identify a lower and upper limit for velocity. These limits can serve as tolerance limits for velocity. The team’s delivery rate is predictable if the velocity falls within these limits.
Visualizing the various velocities observed in each iteration can help identify the predictability of the team’s delivery rate. During retrospectives, the team can use the velocity trend from previous iterations to identify areas of concern. For example, if the velocity falls below the lower limit, it may require an analysis of the causes in a retrospective meeting. Similarly, if the upper limit is breached, analysis may be required.
These limits or ranges in which velocity falls can change over time. However, analyzing the velocity trend can help identify how predictable the team’s delivery is. The more predictable the delivery rate, the more certainty we have in our release planning and future forecasts related to our work.

Using Velocity Metrics to Improve Planning Accuracy

Velocity metrics are a powerful tool for evaluating planning accuracy in agile and scrum. During sprint planning meetings, teams work on a set of user stories and estimate their size using story points. Based on the size of stories planned for a sprint, teams can identify the planned velocity, which is the sum of the story points of all planned stories.
Once the sprint is complete, the team has the actual velocity, the sum of the story points of all the completed stories as per the definition of done. By comparing the planned velocity with the actual velocity, teams can assess the accuracy of their planning.
Over time, teams can analyze planning accuracy trends and identify improvement areas. Improving planning accuracy enables teams to meet expectations and plan realistic work that can be completed during a sprint. While it is not realistic to expect 100% accuracy in planning, identifying the desired level of accuracy over time can help teams improve their sprint or iteration planning.

Velocity and Capacity Ratio

The Velocity to Capacity ratio is a key performance indicator in Agile development as it offers valuable insights into a team’s productivity over time. By comparing the Velocity of completed work to the available Capacity, the team can determine how efficiently they utilize their available productive time and identify areas for improvement. As previously discussed, Velocity refers to the rate of work completed, while Capacity is the sum of productive days or hours available in a given sprint. For instance, if a team of 5 members has 8 productive days available in each sprint, the Capacity will be 40.
Calculating the Velocity to Capacity ratio is straightforward, as it involves dividing the Velocity by the available Capacity. For example, if the sprint velocity is 20 and the team’s Capacity was 40, the ratio will be 0.5. A high velocity-to-capacity ratio implies that the team is delivering a lot of work quickly, which could indicate that they are overworking or burning out. Conversely, a low ratio may suggest that the team must work to their full potential or that external factors, such as dependencies or environmental constraints, impact its productivity.
Tracking the Velocity to Capacity ratio can help the team make data-driven decisions and adjust to changes in Capacity, such as holidays or the addition/removal of team members. By continuously monitoring this metric, the team can optimize their workflow, plan future sprints, and improve their overall efficiency and performance.

Risky Usages of Velocity in Agile

Velocity as a Team Comparison Metric

Using velocity to compare the performance of different teams can be counterproductive. Sizing done in story points are not directly comparable between teams, and each team may have variations in their definition of done and team dynamics. Additionally, teams work with different product backlogs and varying levels of detail and encounter different challenges. Comparing velocity creates unnecessary pressure on team members, which can lead to burnout and poor outcomes.

Agile Velocity as a Performance Metric

Using Agile Velocity as a performance metric to evaluate team success is risky since Velocity is influenced by external factors such as dependencies and impediments. This approach may encourage teams to prioritize quantity over quality, leading to poor outcomes. Moreover, it may incentivize teams to overestimate their work, making the metric unreliable.

Expecting Growth by Some Percentage

Agile Velocity is not a linear metric, and expecting teams to achieve consistent or predictable growth can create unnecessary pressure on team members, leading to burnout, poor quality, and outcomes. It is essential to allow teams to work at their maximum potential and observe Velocity as a learning metric rather than a target metric. Building momentum takes time, and teams should not be expected to increase their Velocity continuously.
In conclusion, Velocity is a crucial metric in agile development that measures the speed and progress of the team. However, various risky and counterproductive usages of Velocity can lead to poor outcomes, including team burnout and prioritizing quantity over quality. To use Velocity effectively, teams must consider best practices such as focusing on Velocity as a learning metric rather than a target metric, using it to improve planning accuracy and delivery rate predictability and understanding its limitations. By using Velocity thoughtfully and strategically, teams can improve their overall performance and deliver value to their customers promptly and efficiently.