Agile Velocity – Good Metric, Use With Caution

The Do’s and Don’ts of Using Velocity in Agile | Previously published to Propelo.AI

Agile velocity is a very simple concept that software development teams use to gauge how many tasks can be performed, or completed, on average within a given timeframe. Unfortunately, while it can be extremely useful within the field of project management, it can also be very detrimental if used incorrectly.

According to Youtuber Gary Tsang, Your Agile Coach, “Agile velocity is one of the most popular software development metrics in the world. When used for an agile team’s sprint capacity planning, it can be extremely powerful. But some people, some organizations and some teams use it for dangerous reasons — evil reasons.”

Agile velocity metrics are best when used in coordinating:

• Backlog to alleviate technical debt
• Project schedules and interdependencies
• Tasks and activities for each member of the team
• Target dates for launch and milestone delivery

And while you can’t measure absolute productivity using velocity in agile, it’s an excellent planning tool that allows users to better understand the dynamics of a healthy team environment — one that encourages productivity while preserving the quality and value of the end-product delivered to the customer. 

What is agile velocity?

Velocity is a metric that shows leadership how successfully teams complete user stories in between sprints. It’s a measure of output unique to individual teams and methods. A sprint’s velocity is often represented as the number of story points estimated between sprints. The average velocity is the median number of story points likely to occur from sprint to sprint. 

What is an average velocity?

Some consider an “average velocity” the most useful metric when planning at scale. It’s the average number of story points the team completes during each sprint (iteration). The sprint’s velocity is represented by how much actually got done from sprint to sprint. Story points are the tasks carried out during each event. 

While teams will underperform one week, they’ll overperform the next. The average velocity is derived from this understanding and used to predict the average number of stories likely carried out at future sprints. It allows teams to plan better and coordinate timelines while making sure to preserve the quality and output of their contributions within the software development lifecycle (SDLC). 

How do you calculate velocity?

1. Add stories up separately for each sprint. This is the velocity.
2. Add up each of the velocities for all three sprints.
3. Divide this number by the number of sprints. This is the average velocity.

Find the velocity of each sprint by calculating the weight of each story between each sprint. Stories are weighted events that are given a point system. The higher the number, the more difficult the task.

The formula is relatively easy.

Let’s say there are four different tasks:

• Coding
• Testing
• Implementation
• Documentation

Now, let’s give each task a weighted score:

• Coding – 5
• Testing – 3
• Implementation – 2
• Documentation – 1

The math looks something like this:

sum of all velocities / # of sprints = average velocity

Each of these tasks was completed between the last two sprints. But over the next two weeks, documentation ends up being missed. During the first sprint, the velocity was a clear 11. But during the next two sprints, stories were only weighted to 10. 

We add up each of the velocities (11+10+10=31) and find the average of all three sprints (31/3=10.3). 

The average velocity for this project is predicted to be 10.3 from sprint to sprint.

Why use story points? 

Story points are also represented by the number of tasks and operations carried out between sprint events. They’re given a relative weight (or number on the Fibonacci Scale) that corresponds with the relative size (XS, S, M, L, XL, etc.) of each contribution (how big a is compared to b). 

While you don’t really need to use story points, it’s highly suggested. It significantly helps to quantify each new sprint and to arrive at an average velocity at each stage of the software development lifecycle.

What you need to know:

• Relative estimation: How large is a compared to b? Comparing one thing to another
• Relative size: XS, S, M, L, XL 
• Fibonacci Scale: 1, 2,3,5, 8, 13, 21, etc. 

Estimating activities is easier than qualifying absolutes (stories vs. hours). There are just too many variables to calculate when working with a team, including the team’s skills, experiences, presence and size itself.

Velocity helps teams plan, but it cannot determine productivity.

Velocities and story points are simply metrics for understanding the bigger picture. On their own, they cannot provide any insight as to how productive a team actually is.

Each team has its own way of relatively estimating stories. The effort of a story point likely varies between agile teams and interactions. The size of the group also influences the number of points completed. 

“Are story points necessary?” asks Jimmie Butler, writer of Pursuing Timeless Agility: The Path to Lasting Agile Transformation. 

“It depends,” he states. “If knowing what you can fit into each future sprint is important, it can help in your planning — and just how many sprints need to be implemented. It starts with relative sizing and assigning a corresponding number (story points) to each size.” 

“Learn the team’s velocity,” he continues, “and apply that against your estimated backlog to predict and plan. This is also great for scalability.”

Using velocity as a performance metric

Using velocity to commit to hard deadlines isn’t really ideal. It’s excellent for estimating the timeframe between start and finish, but it should never be received as “set in stone.” In an agile environment, the process is always moving. And because of this, setting hard deadlines is borderline self-sabotage, because no estimated delivery will ever be exact — especially six months in advance.

Projections are only estimates, which allow leadership to instead identify early starts and prepare for late finishes. Missing a deadline doesn’t mean there was no effort spent. On the contrary, developers often face bottlenecks in the software development process, and additional efforts must be made to address:

• Uncertainties
• Dependencies 
• Issues/Mitigation
• Incident Events
• Backlog
• Technical Debt

And because of this, it’s important to explain to stakeholders that deadlines aren’t always concrete. Communication is everything, and one reason end-of-sprint retrospectives exist. Because most stakeholders don’t understand how there could be delays if everyone is doing their job, it’s important to relay the process and explain how, through this process, value has only increased. 

Does velocity matter? 

Does velocity planning matter? Yes, but you need to be careful. When it’s misused as a metric, there can be more problems than good.

• It’s great for predicting upcoming sprints and schedules.
  It’s easier to plan how much time each sprint should last, and previous sprints can be significant indicators of just that. If a two-week sprint is sufficient, scrum masters are able to plan which tasks may take a while to complete and which tasks are unavoidable. They’ll have a good idea as to how many tasks, or stories, a team can ideally complete between future sprints. 
  
• It’s great for understanding the team’s throughput.
  Taking into account that there will be times when agile teams work beyond velocity and that there are times they will work far below it. Velocity can be used as a metric and a guidepost in getting to know the team a little better. If they perform above a certain quota, they may be able to take on more backlog between each season. But if they’re performing lower, schedules and resources will need to be adjusted to accommodate for where the velocity has fallen behind. It could be a matter of expertise, or it could be a lack of resources. Velocity used somewhat like a measuring stick, is an excellent indicator that other factors must be looked at more independently.

• It’s never great to measure the team’s productivity using velocity in agile, but it can be a great tool when setting a target quota.
  Agile velocity is definitely not a tool for making team comparisons. It won’t provide any additional value outside of its context. And to be quite blunt, it can actually cause more harm than good when used in ways it was never meant. 

Velocity is one of the tools a team uses to self-organize themselves. It’s for the average amount of work a team can complete during a sprint. It is, however, a great tool to use when planning in agile development, primarily if implemented into the scrum framework itself. 

It’s not all that uncommon for project management teams to measure velocity when assigning tasks, developing timeframes and mapping out dependencies. 

Likewise, the development team will learn exactly how many tasks they can realistically take on from sprint to sprint. And the product owner may use the team’s velocity to make projections in terms of release planning and doing away with backlogs.

Does Agile velocity help measure efficiency?

Agile velocity is not a precise measure. It’s based on estimates. And where it can be applied is rather limited. So it won’t work, for example, with teams who have been assembled for short-term projects. But it will prove very beneficial for those who work together on both a regular and more long-term basis.

Velocity requires constant tracking and documentation. Given enough time to mature, the data will be much more accurate. And there will always be an idea of how many tasks can be completed based on past empirical evidence. As the number of stories becomes easier to predict, the velocity between sprints can even advance. 

And if used correctly, teams will master the art of:

• Roadmapping and planning ahead
• Setting shareholder expectations
• Improving and optimizing processes
• Sparking productivity
• Increasing project efficiency

What is velocity in a sprint?

Velocity in agile is ultimately used as a metric to decide how productive the team is from end to end. It’s more or less a guidepost – a measuring stick for where agile teams should be. Factors will include:

• How many stories have been completed during the entire sprint?
• How many points is each story worth? 
• How long is the sprint? 


Let’s take an unrelated industry and compare it to software development:

In the production environment, laborers show up for their shift, ready to work. Now, let’s pretend each shift is really a two-week sprint, where instead of moving actual packages — teams are moving code and data across integrations. 

Ten people show up for duty and are expected to meet a certain quota. And of course, there will be outliers. One or two of them double their quota within the first few hours. Most of the team hovers around the average. And a few of the workers have been performing subpar.

As a team, they’ve reached the expected quota, with some seemingly doing most of the work — and this happens every night. A common occurrence, supervisors know what to expect from the beginning to the end of each shift — and they prepare for it night after night. 

When production levels fall, teams are expected to do more. When there’s not enough work, they take on extra duties — often maintaining the work area or focusing on backorders. 

As an insider looking in, it doesn’t really seem fair. But for leadership, it’s obvious that the numbers aren’t really clear. Supervisors can see how many packages are moved in one night. They can see who’s contributing the most and who’s contributing far less. 

The numbers don’t show that those with the lower numbers perform more consistently. This is because the packages are oversized, cumbersome or too heavy for them to move quickly. So while the top performers double their numbers within the first few hours, it’s the underperformers that carry the entire team through the night.

Stamina, agility, patience and experience. They may be carrying fewer packages, but they carry those packages correctly. Rushing deliveries may mean damaging the product, refactoring and repair. Focusing on quality takes time and stability. While it may take a little longer for them to meet expectations, the work that they’ve done proves to be far more superior. 

Add injury, inexperience and unrelated factors to each shift, and it will resemble a software development team in the midst of innovation. 

The speed and number of packages equate to velocity. And if teams were rewarded — or punished — based on this equation, the entire picture would be forgotten, and both quality and performance would officially be diminished.

Using Velocity to Compare Teams

Velocity should never be used to compare teams in any environment. Doing so can make just about any environment toxic. It’s one thing using velocity as a metric in agile, but using it to measure a team’s speed, quality, load factor, or productivity just doesn’t make any sense. 

Teams work at different paces, and tasks can be carried out differently. Some teams consist of experienced leaders. And other groups are made up of those who find it easier to cut corners. Likewise, stories between sprints will never be equal. 

Velocity, on the other hand, could be used as a more personal metric — allowing individual teams to gauge their own progress and openly discuss it during sprint retrospectives.

Discussing the team’s velocity allows them to better plan for control and flexibility. They could discuss alternative strategies should something go wrong during the development process. Having a notion of velocity enables them to understand how long it will take to finish the process and how they can maximize their efforts to compensate for lost interference.

Velocity in Agile — Why is it dangerous?

Velocity can help teams plan better for deviation, giving them greater control over how they operate as a whole. Using team velocity can be a good thing for coordinating and scheduling, but it can only work if used internally to identify shortfalls in capacity or to ramp up productivity.

It shows teams how well they’re progressing across, based on their timeline for delivery. They’ll know how much leeway they’ll have if they encounter slight difficulty. They’ll learn how to improve as a team and how hard it would be to pad sprints for flexibility and deviation. 

Velocity should be used when planning how many stories can be tackled between sprints and how many sprints need to take place over the course of the entire project. 

But that’s it! It’s just a tracking metric and should be used to measure how hard or how well the team is performing. In the meantime, the dangers of improperly gaging velocity can manifest in many ways:

• Technical debt increases.
• Quality and value decrease.
• Teams are overworked and under-appreciated.
• Engagement and morale take a major hit.
• Transparency is gone, and numbers are inflated.
• Turnover is increased, and projects are delayed.
• Trust is lost.
• The environment is toxic. 
• Data isn’t matching up with reality.
• There’s too much competition and the need to prove oneself.

Use alternative metrics to preserve culture, and decide which metrics should be used instead.

Velocity metrics were meant to be subjective. There are plenty of other ways to better compare agile teams. First, decide which metrics are most important — is it quality vs. quantity? Speed vs. value? Or is it predictability? 

In each one of these situations, alternative metrics are necessary. Deciding which metrics take the team to the next level will determine exactly which metrics will be used when optimizing the product:

• Speed vs. Value: Recycle time metrics
• Predictability: Iteration churn metrics
• Quality Assurance: Measure for defects and rework (bugs vs. issues)

Sprint planning is the building block to success. If your estimates are inaccurate, they are useless or harmful to your initiatives. Now that you know what a story point is and how to estimate velocity, leverage Propelo today to perfect your agile estimations.