What are the benefits and challenges of using velocity as a metric for agile teams?

Velocity, as a metric for agile teams, offers several benefits and challenges. It provides a quantitative measure of a team's productivity and progress, enabling better planning. It helps in understanding the team's capacity, facilitating more accurate sprint planning. However, there are challenges too. Focusing solely on velocity can lead to a quantity-over-quality mindset, where the emphasis is more on completing tasks rather than ensuring their quality. It can also create undue pressure on teams to constantly increase velocity, sometimes at the expense of sustainable work practices. It should be used judiciously and complemented with qualitative assessments to ensure a balanced approach to team performance.

Velocity helps teams assess throughput of the team in delivering value. One of the key measurements that can be used by software teams is how quickly can they generate incremental value to customers. This can be in terms of how quickly can they make a feature available for customer use, or how quickly can they solve a customer painpoint or event how quickly can they fix a problem that a customer is incurring when using the product. Measuring this velocity or throughput of delivery is a therefore a very valuable measurement.

Another hazard of over-indexing on velocity is that over-indexing on it can lead teams to sacrifice quality, or to make poor design decisions. Measuring velocity is absolutely essential, but using velocity alone is no better than not having metrics at all.

Velocity is a great starting point, but it's just one piece of the puzzle ??. As a leader in Business Intelligence, I've seen the importance of contextualizing velocity with other factors like team dynamics and project scope. It's crucial to remember that high velocity doesn't always equate to high quality or value. So, let's not get caught up in the numbers game and forget the human element behind the metrics. Keep it playful, keep it analytical, and always aim for a home run, not just a quick sprint! ??????

Velocity when used as the primary metric presents some challenges. One of the challenges is that, it is not a wholistic measurement. This means, it is incredibly difficult to assess what unit of work should we measure the velocity of. Is it the velocity of writing code? Is it the velocity of releasing code? Or is it the velocity of deploying major releases? Therefore, velocity if used as a metric should be highly contextual for the goals of the team and needs to be supplemented by other metrics that measure the value of the work unit delivered at pace, i.e., quality or customer utilization.

Educating team members is a crucial approach to conceive the importance of consistency in estimation & the impact of scope changes on velocity. Consistent estimation techniques, such as- story points, should be used throughout the project followed by calibrating the team's understanding of different sizes of work. Emphasize relative sizing rather than absolute sizing. Regularly inspect the estimation process. If the team consistently overestimates or underestimates, use retrospectives to understand the reasons & adjust accordingly. Use velocity as a tool to track & identify trends & patterns over multiple sprints rather than focusing on a single sprint's velocity. It enables to monitor the team's performance & adjust planning accordingly.

This is why I see velocity primarily as a valuable output metric for an individual team that should be evaluated longitudinally. That is to say that velocity measures the impact of the factors affecting the team (tenure, attrition, priority changes, etc.). More importantly, it measures the success of leadership efforts designed to improve the team's performance.

There are 3 ways to use Velocity as a metric wisely: 1) Use velocity as an internal measure of Time to Value for a customer. 2) Use velocity as a metric to identify bottleneck in the development and delivery process to enable a smoother workflow. 3) Compliment Velocity with Quality metrics to always ensure whatever is deployed at a high velocity does not compromise on quality. Also one common pitfall to avoid when using Velocity as a metric is to avoid the temptation to use the metric as a performance and productivity comparison tool among teams. This, although commonly done in my expereince, leads to teams unnecessarily gaming the metric.

The only metrics that really matter are customer success, and whether the team is serving customers sustainability and efficiently. Effective team metrics must start with what customers care about. High quality and high velocity are irrelevant if customers don't care. Metrics of quality (such as testing, defects, and ops), efficiency (such as velocity and throughput) and sustainability (such as operational burden and employee satisfaction), must be reviewed together. While leaders may make an intentional decision to accept lower values in one area to focus on another, this makes it even more important to track the lower-priority metric to understand the impact of this choice.

In my expereince, I have found a lot of merit in using DORA metrics to measure the performance of software delivery. The 4 metrics within DORA are: 1. Deployment Frequency — How frequently do teams deploy to production. 2. Lead Time for Changes — The time it takes a commit to get into production. 3. Change Failure Rate — The percentage of deployments that causes production failures. 4. Mean Time To Recovery — How long it does it take to recover from a failure in production or a service interruption. The reason I really like these metrics is because (1) It measures Throughput & Quality, and (2) due to being a standarised metric teams can benchmark themselves against thousands of other teams.

Choosing the right metrics needs a lot of thought and planning. Teams and leaders need to evaluate, 1. The stage at which the company is in, 2. The strategic goals of the company, 3. The technology architecture and team culture, and 4. The needs for implementing metrics. Furthermore, I believe that metrics should reflect the measurement of operational productivity and performance of work. Therefore, leaders and teams need to adapt to changes in their circumstances with changes in metrics.

Velocities can vary to a great extent in delivering Customized applications vs. the Enterprise Products due to various factors like Knowledge Curve, Skill level of Resources, Ease of implementation, Configuration Capability, High Code or Low Code Formats of Development, etc.