Tonight I was sitting here thinking about some of the current issues I’m fighting with at work.  One of the most obvious to me is the fact that we have no project velocity.  After thinking about velocity for some time, I decided that I should put those wandering thoughts to paper…so here we go.

To truly understand the problems I think that my team is having with velocity, I figured that I should first fully understand the definition of the term as it pertains to software development.  My searching around found that velocity can be defined as follows.

Velocity:  The amount of business value that is delivered in each development cycle.

So if you’re in an agile-ish development system, velocity is the number of stories that you deliver each iteration.  It sounds simple enough, but it really isn’t.  Because some stories require greater effort to complete, a simple count of stories delivered within an iteration may be misleading.  In one iteration a team may be able to deliver 10 smaller stories, but the following iteration they may only deliver 3 larger stories.  If we were to simply count the stories delivered, we would have to report that our velocity fell by 70% between the two iterations. 

Instead of using a story count, we should use an abstract estimation value.  The unit of the estimation value doesn’t have to represent anything concrete.  For the purposes of this post I’m going to call my estimation units “peanuts”.  Arguably, I would suggest against using a measure of hours because of some of the negative planning and estimation connotations that it carries around.  So now the people doing estimations are using peanuts to determine how much work each story entails.  When it comes time to measure velocity, you will count the number of peanuts that each delivered story was estimated at and use that as the final tally.  Because this is based more on effort rather than quantity you should get better analysis about the fluctuations that your project will encounter.

So with the definition and method of measurement roughly determined, I’m now thinking that velocity is more than just a math calculation resulting in a cold number.  Velocity is the heartbeat of your project.  The more I think about this, the more I’m believing that I can tell the health of my software development team by listening to the velocity.  If I see that the team’s velocity has been at what I think is an inflated value for an extended period of time, it might be a good sign that I need to let the team step back and take a breather.  Like a heart, teams can flex their muscle and produce at high levels when required, but in the end both the heart and the team need to recuperate. 

Even with the frenzy of development happening around the team, there is always an feeling of the velocity that is being achieved.  The social nature of teams dictates that there will be cross conversation between members about the progress that each is making.  This may happen informally around the water cooler or in a more formal setting like daily standups.  Regardless, every team member knows the feeling when the team is getting bogged down.  Those people that have intimate daily contact with the development effort will not need to see the velocity graphs or numbers to know when things aren’t moving along.  This is good because hard velocity metrics are for the people above you.  The people who have to justify the team’s existence or it’s timeline.  Self motivation at the team or individual level is much better served by the gut feelings and ‘vibe’ that is surrounding the group on a daily basis.  Those feelings are much more real time and thus should allow for a faster diagnosis and response.

One of the things that goes unnoticed with velocity is it’s impact on moral.  Development teams that have attained and maintained an acceptable velocity will thump along like the heart of an athlete.  If the velocity wanes, the extremities will not be nourished adequately and the core of the team will lose the ability to feel and manipulate them.  You will see people loosing interest in keeping the build successful or writing adequate tests.  When you have adequate or high velocity all things need to work together which doesn’t allow for members of the team to forget about the little things that so many rely on.

In the end, velocity brings more to a project than just delivering functionality in a timely fashion.  It’s not just a metric that we can use to judge the iteration to iteration successes and failures of a development team.  Velocity is about the overall health of the project.  It’s more like the EKG of the project than anything else.  You can tell a lot from those blips.