Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Velocity as a goal

  • submit to reddit
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:

Value should be measured at the highest level possible, so that it doesn’t fall into one team’s (or individual’s) span of control. People tend to behave according to how they’re measured and if this metric is easy to game, it will be gamed.

Velocity doesn’t satisfy my criteria for a good performance measure. Quite the opposite, it’s a very easy metric to game

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:

  1. Working longer hours
  2. Cutting corners on quality (by less testing perhaps)
  3. Finding a smarter way of working

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:

The use of goal setting can degrade employee performance, shift focus away from important but nonspecified goals, harm interpersonal relationships, corrode organizational culture, and motivate risky and unethical behaviors. We argue that, in many situations, the damaging effects of goal setting outweigh its benefits.

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

With goals, people narrow their focus. This intense focus can blind peopleto important issues that appear unrelated to their 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.

Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Michael Norton replied on Thu, 2010/04/08 - 1:45pm

Grant and I have engaged in some very heated and healthy conversation around this topic. I crafted a blog post regarding the use of metrics as goals and how this changes a team's behavior (not for the better).

Grant Joung replied on Fri, 2010/04/09 - 11:08am

Young Joo, a friend and colleague of mine once stated, "Only passionate people win." I credit Norton for having an equal amount of passion around this topic which has resulted in a healthy discussion around this topic! I agree now that establishing velocity as a "goal" is not the right thing to do! What I really meant to communicate to the team was an achievable average velocity target that we needed to hit to complete the scope of work we had for a client who demanded completion by a specific date. With a true Agile organization backing a team's work - they should be able to shift the date or scope as the project progresses - but this just wasn't an option with this particular client. It helped serve its purpose on THIS particular project - with a client and industry not known for its Agile practices and demanding that the entire scope and deadline be met. Past project releases on this account had seen chaotic velocity trends which often resulted in heroic work at the end of the project. Establishing an achievable average velocity "target" allowed the team to rally around that number I believe without compromising quality in this case.

Sindy Loreal replied on Sat, 2012/02/25 - 9:03am

The funny thing is that tying velocity to rewards or evaluations serves to ruin it's real value which is in forecasting. The main thing you want from a forecasting metric is that it is an accurate measure(even if it is not even from iteration to iteration).

If one point of velocity from three iterations ago becomes three points of velocity for this iteration then you've lost the value in estimating and tracking velocity altogether.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.