Velocity is the measure of the throughput of an agile team per iteration. Since a user story, or story, represents something of value to the customer, velocity is actually the rate at which a team delivers value. More specifically, it is the number of estimated units (typically in story points) a team delivers in an iteration of a given length and in accordance with a given definition of “done”.

Velocity is a vital component of iterative planning. To see how it is used, consider this example:

1. A team reviews a release backlog with the product owner, and estimates the relative sizes of user stories in units of story points (one story might be sized at 3 points, another at 1 point, etc.). The release backlog, when estimated, totals 120 story points.
    
2. Over the course of several iterations, that same team has demonstrated that it consistently delivers between 18 and 22 story points per 2-week iteration, to an agreed definition of “done”. It therefore considers its velocity to be approximately 20 points per 2-week iteration for planning purposes.
    
3. Based on a total backlog size of 120 points, and a velocity of 20 points per 2-week iteration, it can be determined that it will take this team 120 divided by 20, or a total of six 2-week iterations (12 weeks) to deliver the entire backlog. If the product owner has a hard delivery date commitment that will only allow 8 weeks for the release, then they will only have four 2-week iterations to work with, and will have to decide which 80 story points worth of stories ([8 weeks /2 weeks = 4 iterations] * 20 story points per iteration) are the most important.

So in the case above, size is estimated, velocity is measured, and duration is derived.

When a team is new, it usually takes 3-4 iterations for its velocity to stabilize at a consistent level. Initially, then, velocity must be estimated, and then adjusted at the beginning of each subsequent iteration as the team’s actual velocity emerges. One important consideration is that velocity is a team-specific measure.  A different team estimating the same backlog would likely have different estimates, and more importantly, will operate at a different rate. In the example above, a second team might estimate the overall backlog at 125 points, but only complete an average of 15 points per iteration, so would take a total of 8-9 iterations to finish the project.

The importance of estimating size according to a given definition of done and adhering to that definition is critical. While it may be tempting to push a team to project completion faster than its demonstrated, stabilized velocity, this is a very risky proposition. This is because the increase (if possible at all) will likely come at the cost of having to dilute the definition of “done”, resulting in lower quality and thus more rework downstream. This rework will eventually interrupt planned work, and in the end, will have the effect of actually lowering the team’s velocity.