Is Measuring Velocity in Scrum Good or Bad for Your Team?

Throughout the past few years, the Velocity metric seems to have become a polarizing element among Agile teams due to how this data point is being used. Several years ago, the Scrum Guide mentioned Velocity as a recommended metric for Scrum teams. Because of the way this information has been used and misused, it has since been removed as a recommended practice. Similar to Sprint burndown charts and the use of Story Points, metrics from Scrum teams seems to have become de-standardized, as teams are now free to choose how they track and measure their work.

Now that teams have more freedom, you may wonder whether this is good or bad for the teams. While it is positive that the team has more perceived autonomy, they also are at greater risk of being directed to track and report specific metrics to management because of the absence of an industry standard rule on Agile metrics.

Why Do Teams Measure Velocity in Scrum?

Within the Scrum/Agile world, there is no single equivalent of the PMBOK (Project Management Book Of Knowledge) which provides a formal, official standard organizations and teams can point to as “the guide”. Hence, Scrum teams are potentially under a higher level of influence by senior leadership that expects to see a specific measure of project progress, and Velocity is often the metric of choice.

So is the use of Velocity in Scrum necessarily a bad practice? Let’s look at both sides of the argument and see what makes sense to you.

Pros of the Velocity Metric

Velocity is typically a measurement of productivity by an Agile/Scrum team that usually estimates work using Story Points. The measure Velocity can follow units of Story Points or a simple count of total Product Backlog Items (PBIs). Teams usually track this data point on a per-sprint basis. For example, a team may have planned 12 PBIs (with an aggregate of 70 points) and completed 10 of them (totaling 50 points) within a single sprint. The Velocity is “50”.

The data is typically used to measure team performance trends over a period of time; an average Velocity can assist a team to forecast future output and allow the team to plan what business value they can deliver over the next several sprints.

All this may sound fairly benign so far, correct? When used properly, Velocity trends can be a great tool for a self-organizing, self-managing team. The problem arises when this data point is used in unintended ways.

Why Might Teams Want to Consider NOT Using the Velocity Metric?

In my experience coaching Agile teams, I have observed several practices that lead to undesirable behavior by the team, producing degraded morale and performance. Here are a few examples of such practices.

Cons of Measuring Velocity in Scrum

Comparison of Velocity between teams

Because the Story Point measure is a relative scale that is unique to each team, comparing two teams based purely on the total number of points they deliver is basically comparing apples to oranges; it makes no sense and provides no value. No two teams are identical in terms of their skills, experience, knowledge of the problem domain, interpersonal dynamics, or how they approach their work. So it makes no sense to measure their performance using a single, relative metric like Velocity. Doing so can damage the morale of the teams and motivate negative behavior such as Story Point inflation.

Requiring a Team to “Complete More Points Each Sprint”

One common aftermath of comparing team productivity using the Story Point measure alone is that someone in a leadership role will often mandate an increase in team productivity by directing or requiring a percent increase in output; for example, “Team A must complete 10% more points each sprint.” This will often cause unintended behavior such as teams artificially inflating their estimates just to achieve the directed goal; a PBI that used to be five points is now eight points, etc. This type of behavior puts the focus on meaningless increases in the Velocity metric, eliminating its value.

How to Mitigate the Use of Velocity in Scrum

So how should we try to inspire the proper team behavior towards delivering meaningful business value instead of making the metric look good? There are a few variations of the Velocity metric that can help focus the team on improving their predictability and performance.

Percent Complete Versus Planned

The metric I typically recommend over pure Velocity is percent complete versus planned. We can calculate this metric using points or just a total count of the number of work items. For example, if a team completes 10 out of 12 PBIs (or 50 points out of 70 planned), that is equivalent to 83 percent of stories completed, or 71 percent of points completed. The two numbers will probably vary because of the stories having different sizes.

If the team can track this over time—usually at least three sprints—the team will know the average trend, and that will help answer one important question: Is the team performing consistently? If the graph is showing extreme highs and lows, that shows that they need to stabilize the team. The root cause may be variations in team membership, abrupt changes in team capacity, or changes in priorities during the sprint. All of these potential causes provide opportunities for the team to improve. Generally, as a team matures and learns to work together, the Percent Complete Versus Planned should increase since they should know how to plan and execute work more effectively.

In conclusion, measuring Velocity in Scrum can be a powerful tool that can be used for good and for evil. The key is to pay attention to how you are using the metric, as well as the impact it has on your team. If a metric is helping your team do better work and achieve higher quality, chances are you are using the right one. If not, focus on improving by experimenting with alternative metrics that better achieve the goals you’re after.