What is Velocity? (in agile software development)
Velocity is a term used in agile software development to illustrate the "rate of progress" for a team or a set of teams (i.e. a project/program).
The simplest way to define velocity is: the number or user stories a team/project can do in one sprint ("do" here means that it really is done and potentially ready to ship).
Without the use of velocity you would not be able to draw your teams's burndown, as velocity is the slope of the burndown curve, i.e. how fast are you burning down the stories (or story points or hours) that you committed to for the ongoing sprint.
At a project/progam level, velocity is the rate at which the whole project is burning the User Stories (or requirements) from the backlog.
Also, without knowing your team/project's velocity you can not make longer term planning (over 1 sprint) or even release planning. Hence the importance of knowing your velocity!
In the first 1 or 2 sprints that you run, you will have to estimate your team/project's velocity as you don't have enough data to project your past performance into the future. However, after 3-4 sprints you should start using an average of your past velocity to plan the future and update the release plan.
Note that velocity is a range, not an exact number. For example, if you have developed 2, 5 and 4 stories respectively in your past 3 sprints, then you know that your velocity is 2-5, not 3 or 4. This range will allow you to communicate your best case scenario and your worst case scenario to your stakeholders instead of committing to one single number that is most likely wrong. Always use velocity as a range when communicating outside your team.
In short, velocity is how fast you are developing your software.
Some more resources:
An extensive example and definition of velocity.
A simple definition of velocity:
The mathematical definition of velocity (from Physics).
at
10:00
The simplest way to define velocity is: the number or user stories a team/project can do in one sprint ("do" here means that it really is done and potentially ready to ship).
Without the use of velocity you would not be able to draw your teams's burndown, as velocity is the slope of the burndown curve, i.e. how fast are you burning down the stories (or story points or hours) that you committed to for the ongoing sprint.
At a project/progam level, velocity is the rate at which the whole project is burning the User Stories (or requirements) from the backlog.
Also, without knowing your team/project's velocity you can not make longer term planning (over 1 sprint) or even release planning. Hence the importance of knowing your velocity!
In the first 1 or 2 sprints that you run, you will have to estimate your team/project's velocity as you don't have enough data to project your past performance into the future. However, after 3-4 sprints you should start using an average of your past velocity to plan the future and update the release plan.
Note that velocity is a range, not an exact number. For example, if you have developed 2, 5 and 4 stories respectively in your past 3 sprints, then you know that your velocity is 2-5, not 3 or 4. This range will allow you to communicate your best case scenario and your worst case scenario to your stakeholders instead of committing to one single number that is most likely wrong. Always use velocity as a range when communicating outside your team.
In short, velocity is how fast you are developing your software.
Some more resources:
An extensive example and definition of velocity.
A simple definition of velocity:
The mathematical definition of velocity (from Physics).
My thinking on velocity and Agile Estimation has evolved
If you want to know what I have learned since I wrote this article, check out my #NoEstimates white paper and the following articles:- Simple estimation techniques work! Use the data you already have
- Story Points considered harmful, or why the future of estimation is really in our past
- A better way to predict project release date
- Focus on what matters, a #NoEstimates advocacy post
- The #NoEstimates how to
Labels: commitment, definition, glossary, planning, progress, release planning, term, velocity, vocabulary
RSS link
8 Comments:
This comment has been removed by a blog administrator.
By
Deivi Batista, at October 31, 2008 3:00 AM
@djbuild if you want to plug your tool in a comment then at least have the courtesy of adding some value with the comment.
By
Unknown, at November 16, 2008 10:39 PM
If you end up doing more than just a few sprints/iterations, then using an average works well. Using a range just means you capture the extremes, which by definition is ... an extreme.
If you want a range, then once you have a few iterations complete (say 10) then you can compute the average and standard deviation. You can then say something like:
"It is currently taking us 3 weeks with 95% of all sprints taking between 2 and 4 weeks."
You now have a range, but it now has more meaning than just the two extremes.
This is one of those "try it" techniques, where you can use the average/stdDev along with the range approach. Share it with whomever is interested in performance, and with time you will probably find that folks like the average/stdDev better.
Regards,
Bruce Benson
Project Management Tools That Work
By
Bruce Benson, at December 30, 2009 5:07 AM
@Bruce
What you say is correct in general, but you mention a variable Sprint size.
I would never advise a team to have a variable Sprint size. Just adjust the Sprint size to the shortest time the tam is comfortable with for an iteration and keep the size the same.
That will build ryhtm and a common "yardstick" that helps communication with outside stakeholders.
By
Unknown, at December 30, 2009 8:41 PM
Thanks for this Vasco. I've linked to this article in my blog: http://badiaries.blogspot.com/
By
Colart, at March 02, 2010 5:44 AM
Just discovered your blog and look forward to reading more. In my experience the #1 reason most software projects fail is that some pinhead of an "A" type Manager keeps pushing for tighter and tighter deadlines. They do not intend for anything to be "sustainable", its simply not in their vocabulary.
Its hard to fix stupid.
Obtaining a repeatable velocity that is sustainable and will not by definition NOT burn up your programmers is incredibly intelligent.
By
lamapper, at September 20, 2010 12:51 AM
@lamapper
Thanks. What you say is true. Velocity is a good indication of what is a sustainable pace. Managers can either accept it (and risk succeeding) or ignore (and we know all too well what happens then).
However, my experience is not that managers push for tighter deadline than what was agreed at first (although that can happen). My experience is that things happen as we learn more about the product that change the schedule (some features are bigger, others have dependencies, etc.), and then we don't react to those changes.
By
Unknown, at September 20, 2010 8:19 PM
Thanks. Really helpful :) I appreciate how you can expalin it in easy way so I can understand it without any problems
By
Nala, at March 16, 2018 12:15 PM
Post a Comment
<< Home