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?
- 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.
- 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.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.
Top comments (0)