Agile Glossary

Velocity

What is Velocity?

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

Knowing velocity, the team can compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain approximately the same. This is generally an accurate prediction, even though rarely a precise one.

Expected Benefits

“Worked example:” an agile team has started work on an iteration, planning to complete stories A and B, estimated at 2 points each, and story C, estimated at 3 points. At the end of the iteration, stories A and B are 100% complete but C is only 80% complete.

Agile teams generally acknowledge only two levels of completion, 0% done or 100% done. Therefore, C is not counted toward velocity, and velocity as of that iteration is 4 points.

Suppose the user stories remaining represent a total of 40 points; the team’s forecast of the remaining effort for the project is then 10 iterations.

Velocity is also used to limit the amount of work taken on in further iterations. In our example, the team would be well advised to plan for only 4 points worth of stories in the next iteration. This doesn’t necessarily mean it will complete only that much; in fact, completing story C in the next iteration might mean that the team’s velocity will, on the contrary, be much higher.

Agile teams consider both kinds of events a warning sign: failing to bring a story to completion “or” seeing their velocity “see-sawing”. The expected response is to seek a finer-grained decomposition of stories.

Velocity thus serves in a few different ways as a regulation mechanism.

Common Pitfalls

The above definition of velocity has a few further consequences:

  • velocity is a “measurement”, made after the fact; though it can help plan ahead, it is not itself a budget or a forecast, and phrases such as “setting the velocity” reveal a basic misunderstanding
  • velocity is defined with respect to units of value (user stories) rather than with respect to units of effort (tasks)
  • only the aggregate velocity of the team matters, and the phrase “individual velocity” is meaningless; a team is a mechanism intended to yield more than the sum of its individual parts
  • there is no meaningful comparison of velocity “between” different teams, since such teams may have different approaches to estimation
  • in order that velocity provides forecasts of the project’s end date, it is necessary that all of the user stories making up the project be estimated in a consistent manner; this can be achieved in one of two main ways:
  • estimate the entire set of user stories before the project starts, or early on, such as in the first few iterations;
  • use relative estimation to ensure that estimates made later on are consistent with the ones made at the start of the project

Origins

“Velocity” may be one of the best illustrations that concepts in Agile discourse do not appear full-blown but are worked out over a period of time. Early texts (such as “Planning Extreme Programming”) were generally favorable to measuring “individual velocity”, a practice that fell into disrepute over the next few years. “Story points” became the most widespread unit of estimation, displacing “ideal weeks”. These changes, hashed out over mailing lists, Usenet, and other fora, are sometimes difficult to pinpoint in time, and only clear in retrospect.

  • 2000: the term “velocity” is a relatively late addition to Extreme Programmingreplacing a previous notion of “load factor” deemed overly complex
  • 2002: the Scrum community picks up the practice of measuring “velocity”
Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now