Outside of software development, velocity doesn’t get nearly as much attention in the Agile world as it should. It can easily feel like an unnecessary addition to your process metrics. After all, you and your team know how much work you’re getting done, right?
Honestly, you probably don’t.
Our vague impression of how much our teams are accomplishing just isn’t good enough to fuel real Agile progress. Actually improving your team’s overall productivity requires accurate and consistent long-term measurement of velocity. Without it, you’re left without a reliable way to know whether any improvements you’re making are having a significant effect.
Fortunately, getting Agile velocity right starts here.
Put simply, Agile velocity is the amount of work your team does in a set period of time. But beyond that simple definition, things get more complex quickly. How do you measure units of work so they’re consistent and comparable? What time period do you use? Let’s break each of these down to understand the approaches to Agile velocity you may want to consider.
The first challenge you have is creating a consistent way to measure and compare units of work. Otherwise, there’s no way to accurately track your velocity over time. So what options do you have?
The most common approach is to base your velocity on user stories. These are simple sentences designed to quickly explain who the work is for, what it will help that audience do, and what value they will ultimately get from it. To take the example of the user story behind this article:
As a manager of an Agile team, I want to learn how to better use Agile velocity to ensure my team operates at its best.
Other approaches include using hours of time engineers spend on work (great for engineering teams, but fairly limited for anyone else), and story points. But for the vast majority of business agility use cases, we recommend user stories because they help teams not just track what needs to happen, but focus that work on providing value for stakeholders.
Of course, two user stories can represent dramatically different amounts of actual work, so the second critical part of the equation is estimation. This is when your Agile team comes together to estimate how much work all its user stories will take. You can measure work in hours, days, or anything really as long as it’s a consistent measurement you can apply to all of your work.
Many teams use games or tools to help ensure their planning is accurate and improves over time. For example, planning poker is a favorite way to gamify planning for better Agile velocity estimation and tracking over time.
So once you’ve chosen a unit and a way to estimate the amount of work it will take, you can begin to track how many of those units you think you can accomplish in a set amount of time. When you’re using Scrum or Scrumban, that time period is easy because you can just use your sprint.
Congratulations, you have a way to track your team’s real output over time! Now it’s time to put that knowledge to use.
Continuous improvement is at the heart of Agile. But accomplishing it requires the ability to measure improvement to determine whether or not a change you made is really making a difference.
Always ensure you begin with a good experimental design. This involves ensuring other variables are consistent (if you change 4 different things about a sprint and get great results, it’s almost impossible to know which of them really made the difference), knowing exactly what hypothesis you’re testing, and ensuring your results are actually statistically significant.
Only by tracking your team’s Agile velocity properly can you set up good experiments and learn what makes your team more effective.
Even if you’re already measuring your velocity, chances are you can improve how you do it. Here are a few techniques you can employ for better Agile velocity measurement.
The aforementioned planning poker is one of our favorite ways to improve estimation. But whatever strategy you use here, be sure you track how accurate your team’s estimates are. So, for example, if your team estimates a task will take 4 days to complete and it takes 8, it’s vital you try and understand what went wrong with that estimation so you can do better next time.
Relying on teams to manually track velocity is inviting problems. Inevitably, someone will forget to track something or type in a value incorrectly, messing up the data you rely on to improve. That’s why automated velocity tracking tools are so useful.
In addition to simply automating a lot of manual work, they usually offer more advanced analytics and analysis tools, empowering you to uncover more insights. So begin by checking whether any of the tools you currently use offer this feature and, if not, you can find lots of good options online.
As mentioned, one of the most important steps in using Agile velocity is tracking and addressing what goes right and what goes wrong. Retrospectives are the best time to do this. Take them as an opportunity to talk through your estimation and velocity to see what successes are worth celebrating and doubling down on as well as failures that should be addressed.
Besides everything we’ve mentioned so far, there are a few other issues you should keep an eye out for.
First is focusing on individual instead of team performance. If you have single team members who are excited about their velocity, you’re actually hurting your team’s performance. Optimizing the output of each individual and optimizing the output of the entire team are two different things. You want to avoid a situation where each individual on the team is trying to optimize their performance instead of thinking about how to work together so the team achieves its goals.
Another issue to watch out for is comparing teams, particularly teams with different functions. The point of Agile is not to get a bunch of teams to work and see who’s best. The point is to maximize the quantity of value delivered to stakeholders. If your Agile teams are using velocity tracking to see who’s best, they’re missing the point and getting away from Agile.
Finally, you should be on the lookout for inconsistent user stories. Because they form the bedrock of most velocity tracking, it’s extremely important they are done consistently. Be sure you follow the basic formula of “as a… I want to… so I can…” Otherwise, you’re stuck doing something akin to building a house out of bricks that are all different sizes, and you don’t need that kind of a mess.
One key theme throughout our discussion of Agile velocity is that it has to come from a strong foundation of Agile fundamentals. Otherwise, it’s easy to forget why you’re tracking velocity at all. Soon you’re falling prey to the common challenges we just mentioned and even drifting towards “fake Agile.”
Luckily for you, it’s now easier than ever to avoid all of that by taking a Business Agility Fundamentals course. By starting with a basis in Agile principles, you’ll be better equipped to nail Agile velocity and set your teams up for success. In particular, it will enable you to better understand how you can fit Agile into the way your organization works, and apply it to key areas like recruitment, sales, and reporting.