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: https://agilelearninglabs.com/2009/01/track-velocity-not-time-spent-on-tasks/
What’s an accurate estimate?
Dave,
Estimates aren’t accurate. If they could be accurate, we wouldn’t call them estimates; we’d call them measurements. We estimate when we don’t have full information. In complex work domains, such as software development, there are always unknown unknowns. This leads to variance in how long things take to implement. The good news, we can give the business good predictability on average. If we know the average rate of delivery, usually called velocity, then we can provide useful answers to questions like:
“How much stuff will be done by the end of the quarter?”
“How likely is it that this item will be done by the end of the quarter?”
“How long will it take to get this set of stories done?”
Here are some links to articles and videos that explain this in more depth:
Don’t Change Estimates In Sprint Planning
Easy Estimation With Story Points
Story Point Accounting Across Sprints
The video Agile From The Perspective Of The Product Owner covers this well.
Cheers,
Chris Sims