In the end of each iteration, the team measure the effort associated with user stories that were completed during that iteration. This total is called velocity.
Knowing velocity, the team can revise (or compute) 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 100% precise one.
“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.
Velocity thus serves in a few different ways as a regulation mechanism.
The above definition of velocity has a few consequences that will be displayed above, but the most common one is: velocity is a “measurement” what can lead to a 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 provide 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.