Jul
20

What is Velocity on Agile or SCRUM projects?

4 Comments

Velocity is a term that is used very regularly in the Agile world, so let’s talk about it……

Dictionary Definition

Back in high school science class, we were told that velocity is the “rate at which an object changes its position”. Now, I was always pretty sure that this is what laymen referred to as “speed”, but speed has no concept of direction (I just checked wikipedia). So you could drive your car around and around in a circle as fast as possible, but as you always come back to where you started, your velocity will be zero.

So let’s now say you are driving down a nice open highway, heading north at 100 km/hour.  In an hour, you will travel 100 kilometers in a northerly direction, so this is your velocity – 100 kilometers per hour.

Disclaimer – I am not a Scientist or at all into Physics, so please correct my definiton in the comments!

Agile Definition

The Agile Defintion is much easier!

Breaking your project into Iterations and getting regular feedback on the iteration is the essence of Agile.  In simple terms, velocity in an agile world is the amount of work that you can do in each iteration. This is based on experience from previous iterations.

357714In order to get to an actual number, you need to look at the estimates from your previous iterations.

So let’s say you had the following stories and estimates below;

  1. Story 1 – 2 Days –  As a Manager, I want to see all Sales for the month, to aid in planning.
  2. Story 2 – 3 Days – As a User, I need to change my password, to protect me from fraud.
  3. Story 3 – 1 Day – As a User, I want to see all previous purchases, so it is easy for me to reorder.

In total, you estimated that 5 days of development was required to complete the iteration. So in this example, your velocity will be 5.

NB// SCRUM recommends using story points to estimate, rather than days. We will discuss this in another blog!

So why is it important?

After you do a few iterations, you will become better at estimating and your velocity should start to stabilize. With a stable velocity, planning releases and iterations becomes much easier. Management and the business are also loads happier as you are delivering standard size iterations with less surprises.

Posted in Uncategorized
4 Comments Posted by Adam Feldman

4 Responses to "What is Velocity on Agile or SCRUM projects?"

  • Thomas Nilsson says:
    July 23, 2009 at 7:56 pm
    Reply

    I totally agree that a stable and visible velocity is important to every one.

    But the velocity is not what you think it will take you to finish the iteration. It is how many items of functionality that you actually delivered. Developed, tested, integrated, documented and deployed preferably.

    I have found that estimating in days often trips you off because it retains the sense that the amount of work can be predicted, and hoping that you are right, and promosing. Development is an uncertain activity and there is no way that you can, in a particular case, know up front what amount of work will be required to get to the solution. You will also forget some of the activities in the list above, which will set you off by a factor of say 2-5.

    Therefore it is easier to get into a habit of inspect and adapt if you go with story points from the start. This takes away the guessing and tweaking of expected work. Instead you can measure how many points you delivered in a fixed timebox.

    If you estimate in days or hours everyone will still think that we do one estimated day in one working day. Which is not true.

    Velocity calculation with story points is a statistical way to measure progress since you don’t have to guess right on every story, the important thing is that you do the same type of guessing with the same prerequisites and facts every time. Then velocity is what you measure it to be, there can be no tweaking or hoping.

    • Adam Feldman says:
      July 27, 2009 at 8:09 am
      Reply

      Hi Thomas,

      Thanks for your detailed response, it is much appreciated. I had a look at your blog and it looks like you have a wealth of articles for keen agilistas also!

      I 100% agree with you that story points are probably a better way of sizing work than ideal days as I spoke of in my article. When I was initially getting my head around many of these Agile concepts, one I initially struggled with was story points. I thought I would pass this lesson onto my readers and first explain velocity before venturing into story point territory. I will be writing an article on story points in the next week or two, I would appreciate your comments also.

      Now I have a question for you! I do not understand your point;

      But the velocity is not what you think it will take you to finish the iteration. It is how many items of functionality that you actually delivered. Developed, tested, integrated, documented and deployed preferably.

      Velocity for me is a simply rule that the amount of work done in previous iterations, can probably apply to future ones. If in previous iterations I managed to deliver 10 large stories and 5 medium stories and I have kept this up for about 5 iterations, odds are that this is a pretty good indication of how much we will deliver in the current iteration?

      I look forward to your thoughts.

      Adam

    • Adam Feldman says:
      July 30, 2009 at 10:55 am
      Reply

      Hi Thomas,

      I had reread your comment and as a result updated the original blog. You are right, it was not clear in my initial blog that velocity is calculated based on previous iterations. The real benefit of knowing your velocity is so you can use it to roughly estimate what you can squeeze into the next iteration.

      Thanks!

  • Byron says:
    July 2, 2010 at 3:42 am
    Reply

    I have been trying to find the better way to explain to my team, which is recently adopting Agile practices based on SCRUM process, the difference(s) between Story points and amount of work represented in hours. Any advice will be helpful… Thanks

Leave a Comment