High Velocity ≠ Effectiveness

Teams that are using the Scrum framework to become more Agile usually use velocity as a metric to help them understand how much value can be accomplished in a given sprint—which also gives a good idea of what value the release can hold.  This metric is something each team strives to improve through continuous improvement of their processes and teamwork.  However, the meaning is not altogether taken at face value…

When you think of velocity, what do you think of?  Do you think about the higher the number, the better or equating velocity to the amount of work the team does?  Does your team strive for high velocity?  If so, why?

Teams use velocity for a multitude of reasons; few of which are actually valid.  These valid reasons usually include improving themselves, using it for planning purposes, and sometimes for proving their abilities as a team.

When you remove the valid reasons, there are many other reasons that velocity is used as a metric, and some of them are not so ‘friendly’ to the team, or to being Agile.  A few I have heard or seen include: measuring the team’s pace, using it to force the team to do more than they are really capable of, using it to mix up teams, having it prove that “Agile fails”, apply it as a way to show risk to the project, and, maybe the worst, using velocity as a way to push the team into a ‘death march’ to completion.  I have seen many teams that end up failing because someone, who may not understand the purpose of velocity, pushes the team over the edge and they “storm” over how they should be working.

When we look at velocity, it is indeed meant to measure the throughput of the team in a given sprint—how much the team completed during the sprint.  The original intent of this measurement is to assist in planning the amount of work that the team can accomplish in a sprint, and therefore how much scope can be accomplished in a given number of sprints, or a release.

By looking at the definition and the original intent, you can clearly see how the intent can be morphed or twisted into some other purposes, like those listed above as the ‘not-so-friendly’.  This is not unlike many large companies in their infancy of an Agile transformation—they are not sure what to do with this new metric and so they use it as they see fit, even if it’s not the purpose.  When this happens, it tends to cause riffs inside the teams and across teams.  The worst scenario is when organizations that do not have the proper training or coaching in Agile attempt to ‘read between the lines’ and begin to infer things about the team, such as how hard they are working or even whether they are working at all.

It is important to understand that numbers do not tell the whole story, but merely start the conversation.  The conversation is worthwhile so that the team, and the organization, can better recognize what is happening with the team and how they are attempting to become more Agile.

Another murky side to how some teams’ velocities are used is to compare team to team—as if a higher velocity by one team over another means there is a better team.  The idea that teams can be compared by simply comparing velocities is a bit absurd—there are so many reasons that one team’s velocity may be higher than another’s, which is more evidence that numbers do not tell the whole story.  When velocities are used to compare team against team, you find that it creates friction between teams.  As the relationship between teams is strained, the value that the teams produce begins to dwindle or be of less quality.

Velocity is one thing that a team should never compromise; their velocity is what helps to keep them on a more sustainable pace and helps prevent them from getting burned out.  The biggest thing that velocity gives a team is a way to keep from committing to more than they can realistically deliver.

After reading this, would you change how you measure your team’s, or teams’, velocity?  Does it change how you interact with other teams?  Feel free to comment on how you use, will change, or see velocity.