Agile Velocity: The Art and Science of Consistent Performance

Imagine that your team sets out to win a race.

The first team to run all the way across the US will win a prize.

Which approach do you think is best?

1. Your team takes off in a dead sprint from California, gets tired quickly, and then collapses on the roadside for several days while they recover.
2. Your team studies their own performance, decides how long and how fast each of them can run, then creates a plan to job at a reasonable pace until they reach the finish line.

Obviously, the latter is clearly a better approach. And the same holds true when we talk about an agile team’s velocity.

Software development is like a marathon. Sure, there are individual “sprints” or iterations. But, in the grand scheme, it’s a long, continuous process.

Speed and productivity matter, but consistency is the hallmark of a great software team.

What’s a good agile velocity?

In agile software development, velocity is a critical measure of performance.

An increase in velocity may signal an improvement in productivity or growth in skills and understanding–but your team should be focused on delivering a consistent performance, not just bursts of productivity that can’t be maintained.

So, what velocity is considered “good”? It depends–entirely–on your team.

Your goal should be to find and optimize a sustainable pace of work.

So, what’s “good” is entirely relative. The best velocity for an agile team is one that is predictable and consistent.

At its most basic, a team’s velocity tells you how much relative work they are able to complete within a given timeframe. As the name implies, it’s a measure of speed.

But this is only a simple understanding of what an agile team’s velocity really measures.

If we consider that most agile teams measure their velocity only on the basis of 100% completed user stories, then it’s clear that velocity is not just about productivity–it’s about reproducibility. It’s just as much a measure of management’s ability to set realistic expectations (or teams to estimate their own abilities) as it is a measure of the team’s capacity to complete tasks.

Unfortunately, many teams (or, perhaps more commonly, managers) misunderstand the role that velocity plays in measuring and managing performance.

The point of measuring an agile team’s velocity is not to expect a continuous rise in productivity. That’s both unrealistic and a misunderstanding of the design of agile velocity as a measurement.

A team’s velocity should be determined by their past performance and their ability to estimate work.

Velocity, taken as a whole, is useful for diagnosing problems and/or measuring improvements that occur over time. The most important part is not to improve velocity, nor its absolute measure. The important thing is the consistency over time and ability to use velocity to forecast and plan for backlog items over multiple iterations.

How to improve your agile team’s velocity

As I’ve already laid out, it’s important to keep in mind that “improving” your team’s velocity does not necessarily mean that there is an increase in the measure of velocity.

That being said, there are some things that generally lead to improved team performance and more consistent velocity measurements. It’s part art and part science. Although these outcomes largely come from gained experience, there are some changes to process that can help.

Improved and more consistent velocity comes from:

Better teamwork and collaboration

Velocity as a measurement and agile development as a process revolve around a central unit: The team.

While it’s often tempting to measure the performance of individuals on any given team (especially with regard to productivity), this is almost never helpful. Instead, focus on facilitating better teamwork and collaboration. Find ways to improve communication between members of the team to provide support wherever necessary.

At 7pace, the team uses time tracking as a granular measure for individuals within the scope of an iteration. This allows each member of the team to understand when and where they can help each other to achieve the scope of work they’ve agreed to complete.

More granular user stories

One common pitfall for agile teams is how they scope and define user stories.

A fundamental part of this process is the importance of breaking down a user story into its most basic elements. Ideally, each user story should comprise only a small number of story points.

If your team finds that an entire iteration is taken up by only a few large user stories, then it’s easy for an entire user story to be incomplete. This will likely be reflected in a large dip in velocity for that iteration and introduces a lot of uncertainty and extra work for forward iterations.

Continuously work to refine user stories into more granular units of work that can be more easily included and completed within a single iteration.

Improved estimation by keeping teams together

Part of this process just comes from experience.

As a team works together on the same products or projects for long enough, they begin to improve their estimation skills. While they may have been wildly inaccurate–and inconsistent–in their estimations early, they will begin to improve as time goes on. Keeping teams together is an important part of this learning and growing process.

Keep in mind that velocity is a feedback loop in and of itself. The velocity that a team sets should be based on its history of productivity, not an arbitrary number dictated by management.

Elimination of outside pressure/overwork

It may seem as though one way to improve a team’s velocity is to simply cram more user stories and points into a given sprint.

In reality, this almost always has the opposite effect.

Most teams only count completed user stories when measuring their velocity. That means that any incomplete or partially completed stories will not be included. So, if the scope of work is simply too large to complete within a given iteration, then the velocity will likely suffer overall.

Teams need autonomy to know their own capabilities. Having additional work piled on helps no one. It destroys the process and undermines the design of agile software development as a process.

Better processes and systems

Lastly, there is often performance to be gained by simply improving the planning or development processes and systems.

Many teams fall into a specific workflow that they use again and again. But, much of the value of agile software development is its iterative nature. This gives you the chance to learn, try new things, and improve your systems.

Use retrospectives as a chance to identify possible improvements and then test them in future iterations to measure their effectiveness.

Keep in mind that processes and systems aren’t necessarily about raising velocity per se. It may be a matter of improving the way that your team estimates or reviews work that’s completed–how it leans.

Velocity on its own is important, but “speed” for the sake of speed shouldn’t be the ultimate goal.