What is Velocity Good For?

Posted by Amr Elssamadisy on Jul 06, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Team Collaboration ,

Delivering Value ,

Agile ,

Agile Techniques

Tags

Coaching and Mentoring ,

Coding Standards

A recent discussion on the ScrumDevelopment Yahoo! group discussed the different uses and misuses for velocity.  Kurt Häusler described his understanding of velocity and its value:

Hi, velocity is measured by counting the number of story points done in the last iteration. I am not sure if it is suitable as a productivity metric. For me it is a neutral measure to be used as a tool to work out how many points to attempt next iteration. A lower or higher velocity for me is not necessarily better or worse.

However velocity is an important tool, if you understand what it is and what it is for, which as far as I know is planning the next iteration rather than measuring productivity.

Kurt also acknowledged that this is not the only view on velocity by Joe Little's blog where Joe states:

...we will double the team's velocity. In 6 months or less.

Doubling velocity (story points done-done in each sprint) usually means we must improve several things:

• a clearer definition of done (or "done, done" if you prefer). Usually we let this be too vague. Vary it must for some stories, but for most SW dev stories it must be very clear and can be consistent. And in my opinion, it must mean "no [known] bugs escape the Sprint". And testing must include at least functional testing.
• we must measure velocity. I still can't believe how many teams I find that don't have some measure of velocity. More on this next time. For now: "Velocity: don't leave home without it."
• we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled. Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.
  
  Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.

 Adam Sokra agreed with Kurt that velocity is a poor performance metric, but sees velocity's main utility in long term planning instead of iteration planning:

It is an exceptionally poor performance metric, unless your intent is only to see how your productivity stabilizes over time. Velocity has been used to say, "last iteration we completed X points, so this iteration we should attempt no more than X." However, many of us have come to believe that this is a dubious way to make commitments. It has been suggested that we simply commit to what we think we can accomplish each iteration.

Velocity is best used for long term planning. I can look at my velocity over several iterations and come up with an average (Preferably a range.) Then I can use that information to say things like: 1) Given the current backlog, how many iterations is it likely to take to complete a given set of stories? 2) How many story points, and by extension what set of prioritized stories, can I deliver by date X (e.g. in time for the trade show?)

And, of course, there is a growing school of thought that views planning as a wasteful activity.

Should velocity be used a metric for productivity?  Should it be used for iteration planning?  What about longer term release planning?  Should it be used at all, or is it a wasteful practice?

1. Back to top

   Measure the output, not the input

   by rob bowley

   I am very wary of anyone who suggests increasing velocity is a goal. *They are just estimates*. It is so easy to game. I've seen it happen both consciously and subconsciously with very undesirable effects.
   
   
   
   The only measure of increased productivity is completed work. Measuring this also has the desirable side effect of encouraging people to break work down into the smallest possible deliverable units.
   
   
   
   Measure the output not the input.
   
   
   
   On my team we find velocity very useful for controlling our capacity and giving stakeholders an idea of delivery schedules but it is certainly not something we strive to increase. What you desire from velocity is stability.

   Reply

2. Back to top

   Re: Measure the output, not the input

   by Yao Scott

   Agree.
   Velocity of team should be stable, maybe increasing step by step.
   Points of stories is estimated. Howerver, when the story is picked up, the number of points should be a commitment. Ofcouse, it is acceptable to refine the points if it is far away from the reality. This will help to build up self management and keep velocity stable.

   Reply

3. Back to top

   Where Velocity Breaks

   by Mike Cottmeyer

   One key thing to keep in mind about velocity... it only works if everyone can deliver value independently. Good team performance (however you measure it) is only relevant if all teams required to deliver the value stream are performing well. In a dependent system, velocity is a poor indicator of overall enterprise performance.

   Reply

4. Back to top

   Re: Where Velocity Breaks

   by Laz S

   @Ewok_BBQ - I RT'd this

   Reply

• Older >