Velocity Is Speed, Not Distance Covered

Bart has been in ecommerce for over 20 years, and can't imagine a better job to have. He is interested in all things agile, or anything new to learn.

  Agile  

As the new year rings in, teams inevitably talk about the goals and objectives for the year—and what ways they hope to improve. At some point, someone will talk about improving efficiency, or attempting to accomplish more this year than they did this year.

In itself, this isn’t a bad thing. It’s the sign of a good team that it is always looking to improve, either incrementally or by making big changes in how the team operates. For an agile team, one of the points of holding a team retrospective is to figure out how to do more of the things that are working, fewer of the things that aren’t. Overall, continuous improvement is a good thing.

One of the problems in software development is that “more” is a difficult concept to understand. Does that mean to deliver more features? More lines of code? More Jira tickets? What exactly do we mean when we say we want to deliver more?

Eventually, the team will hit upon the only measure that agile uses in this area, velocity. A team’s velocity is the measure of how much work, usually measured in story points, that it accomplishes each sprint. It’s actually a simple measurement; the team adds up the story point value of all the stories that were completed in previous sprints, averages them out, and the resulting number is the team’s velocity.

So it would be equally simple for a …

Please log in or sign up below to read the rest of the article.