As I travel around talking to Scrum teams, developers and pretty much anyone involved in building products, they seem to always bring up “velocity.”  Don’t get me wrong; velocity is a good measure, but it is only ONE measure, and it is one that can be quite subjective as well.

In Scrum, for example, teams will get together to understand the work items that exist in the Product Backlog and then estimate the amount of effort that it will take to complete those items.  The estimation can be done in many ways, including Story Points, T-shirt Sizing, Dot Voting and more.  It doesn’t matter what form you choose; what is important is that you are consistent in how your team measures.  This will become more consistent over time as the team forms and learns to work together, and you should consider what things mean to the individuals on the team.

RELATED CONTENT: Scaling Scrum is just Scrum

Understanding a team’s velocity can be quite a powerful tool.  It will help the product owner and the overall team approximate what can be accomplished during a sprint. Sizing will help the development team break up work amongst themselves, determine if the work item is too big to accomplish and needs to be broken into smaller pieces, knowing how much has been accomplished and predicting what can be accomplished in the future.

While sizing and velocity can be excellent tools, they are too often weaponized.  As discussed above, they are great for helping to forecast and understand; however, those measurements are not set in stone.  Sizing is truly an estimate about what we know at the time. As we start working on something, the effort may increase or decrease based on what is learned while doing.  

Say we are using the Fibonacci sequence. The sequence is a mathematical series of numbers. The series is generated by adding the two previous numbers together to get the next value resulting in the following series: 1, 2, 3, 5, 8, 13, 21…. 

As an individual or a team, a 5 can mean something different than it does to another individual or team.  As the team members grow to know each other and how they work, they will learn from and about each other to gain a common understanding of how they each size, and become more consistent as a team in their estimating.  

There are two common places where I often see the weaponization of velocity:

  • Giving new velocity targets for teams and individuals
  • Comparing one team’s velocity against another’s

When we start holding teams or individuals accountable for a specific velocity, they are often inclined to start upping their estimations. What used to be characterized as a 2 is now estimated to be a 3 and 3 is now estimated to be 5 and so on.  They know that they are being measured on the increased velocity so they start to “cheat the system.” This isn’t always done on purpose. Sometimes it is just the feeling that they are underestimating because they are being hammered about not delivering a velocity of x makes and they know that they did as much as they could.

When comparing teams’ velocity, you get completely away from the team and individual aspects of estimation and why they are doing it.  Each team and individual is estimating as they see fit. It really doesn’t matter if they estimate an item to be a 3, 5 or 8 as long as they over time are consistently understanding what that means for them in terms of forecasting and work loads.  Because they are a team using estimation as a way to plan and consistency is learned over time, it is nearly impossible for the entire organization to estimate exactly the same.  

The estimation of a 3 to one team may honestly be a 5 to another and that is perfectly fine, because they know what that means to them as a team.  Over time, we can use this as a great way to see if an individual team is becoming more effective, estimate when work will be complete and when we are putting too much work on a team. However, using increased velocity or comparison of team-vs-team velocity will drive more poor behaviors than good ones.

As team members work together, they become more efficient, learn how to work together and get better at estimating the effort and capabilities of the team. To get a true evaluation of what a team or product is delivering, move from amount delivered to value of what is delivered.  Start measuring the impact of the product on the overall organization, users and ability to deliver more of what they want and need. We can easily deliver more of the wrong thing rather than focusing on delivering the highest value items to achieve true success.

What will cause disruptions rather than be of value is when we start to force measurements and comparisons rather than using measurements as a way to be more predictable and deliver higher value.