The rate at which an agile team completes work, used not to measure progress per se, but to accurately estimate the team’s capacity for future iterations and guide the team and product owner in planning upcoming iterations.
In the first iteration, a team has no velocity; they take a flying guess at how much work they will complete. But from iteration two onward, velocity is derived from the amount of work the team completed in the previous iteration or iterations.
Different teams use different units of measure for estimating work and determining velocity, some of the most common being: story points (Scrum), craft units (XP), ideal days or hours. The team may determine its velocity by averaging the amount of work completed to date over the number of iterations completed (work/time), or simply by taking the amount of work completed in the previous iteration and carrying it forward.
The data used to determine a team’s velocity may be documented on the project Burn Down and Burn Up charts.

Background of the Term

Originally, advocates of Extreme Programming estimated in terms of Load Factor, which was the inverse of velocity, being time/work. “We think velocity is the simpler term, so Load Factor is falling out of use,” Robert C. Martin wrote in 2000. Kent Beck said much the same in his 2000 book, Planning Extreme Programming: “We used to use load factor a lot in planning, but since then we have learned that it’s easier to just use velocity.”

Further Learning

An Agile Learning Labs blog post:

This entry was posted in v. Bookmark the permalink.

2 Responses to Velocity

  1. Dave Collins says:

    What’s an accurate estimate?

Leave a Reply

Your email address will not be published. Required fields are marked *