Grant Joung wrote a post a while ago about velocity goals and whether they’re a good or bad idea, a topic which seems to come up from time to time on agile teams.

My colleague Danilo Sato previously wrote about the dangers of using velocity as a performance measure because it’s something that’s directly within our control and can therefore be gamed:

Danilo suggests that we should look to use metrics which are outside of our immediate control but which we can score high on if we focus on doing a good job. He cites the 'net promoter score' (that measures how much your custumer is willing to recommend you to a friend) as an example of this.

Dan North gave a really good presentation titled 'Our obsession with efficiency' where he covers similar ground and touches on the gaming of performance measures.

From my experience having velocity as a goal doesn’t make any difference to the motivation of the team which is often cited as the reason for referring to it as a target.

In all the teams I’ve worked on people are giving their best effort anyway so they can only really have an impact on the velocity by doing one of the following:

With the 1st idea we now have an inaccurate representation of how much work we can actually complete in a given time period so our future planning is now made more difficult unless we insist that people work long hours all the time which is a recipe for disaster.

With the 2nd we will eventually suffer when there are more defects later on in our process and we have to come back and re-work those bits of the system.

The 3rd is good but then again I don’t imagine that we would need to have a velocity goal in order to start doing that - we should be working smart by default.

I recently came across an interesting paper titled 'Goals gone wild' which suggests that goal setting can actually be detrimental and that we should be more careful about how we use them:

Setting velocity as a goal is a prime example of what the authors call a narrow goal:

As Danilo points out what we really want to do is to get some features that our users want to use into production with as few defects as possible so that they actually work.

Our underlying goal might therefore be to make the lives of our users easier through their use of the website we’re building.

This is much more difficult to measure which is perhaps why the number of points completed becomes the focus when in reality that’s not what anyone cares about. It seems more to signify a lack of trust between the two parties.

In reality I haven’t noticed that people on the teams I’ve worked on pay that much attention to whether velocity is considered a target or not. People just do their job and we pretty much always have the same velocity each week regardless.