loading...
Cover image for Agile Velocity: The Art and Science of Consistent Performance
7pace

Agile Velocity: The Art and Science of Consistent Performance

madeby7pace profile image Devs @ 7pace ・2 min read

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.

Alt text of image


7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.

Alt Text

Posted on by:

madeby7pace profile

Devs @ 7pace

@madeby7pace

Account for the devs at 7pace because we all write but don't want to deal with multiple accounts. Check out 7pace Timetracker for Azure DevOps (and soon GitHub)

7pace

If Engineering Was a Guessing Game, Anyone Could Do It. We take the guesswork out of planning and reporting for development teams using Azure DevOps (& soon GitHub)

Discussion

pic
Editor guide