The Value in Velocity
As Agile Coaches, we are often placed in client engagements where Scrum teams are challenged with Scrum practices. One facet of Scrum that seems particularly challenging for many organizations and Scrum teams is an understanding of the value and importance of team velocity.
Scrum teams know that velocity is an indication of the amount of work that a team can accomplish in a given sprint. Velocity is calculated by adding up all of the completed story points and dividing the sum of the story points completed by the total number of sprints completed at the time of the calculation. Story point values are relative estimates of the perceived level of effort necessary to complete a sprint backlog item (a user story) and as such, a team's velocity is not particularly useful by itself. However, velocity becomes a valuable metric over the course of the project as the team completes multiple sprints and establishes a consistent velocity.
A consistent team velocity allows a Scrum team to:
1. Create a Release Burndown chart that shows project stakeholders approximately when the user stories on the project backlog will be completed (this chart will change as more stories are added to the project backlog and individual sprint velocities change).
2. Predict the amount of work the Scrum team might possibly accomplish during a sprint (useful in Sprint planning).
3. Measure a Scrum team's work progress from Sprint to Sprint.
On most occasions, when "the business" requests work from a project team, sooner or later the question, "When will the work be completed" comes up. This question is answered with the Release Burndown Chart. The Release Burndown Chart typically depicts an "ideal" line and an "actual" line that shows the progress of the Scrum team in completing Project Backlog items. I encourage the Scrum teams I work with to update the Release Burndown Chart at the completion of each sprint so that the Release Burndown Chart accurately reflects the progress of the project team and provides project stakeholders an idea of when the project will be completed.
Established Scrum team velocities also help the Product Owner with sprint planning. The Product Owner can look at the team's established velocity to determine how much work the team can potentially accomplish in the next sprint. While team velocity should not be the sole indicator used in sprint planning, velocity does provide a "starting point" for the Product Owner and Scrum team when determining the total number of user stories (and associated story points) that can be introduced into the sprint planning meeting for the upcoming sprint.
Another valuable aspect of tracking velocity is the ability to observe how a team develops over time. If a team consistently increases its velocity, it can be inferred that the team is learning to work together better and incrementally improving its performance. Conversely, if a team's velocity is consistently decreasing, it can signal a problem with the team performance that could be investigated in the sprint retrospective.
I believe that tracking velocity is a valuable process. However, the limits of its value must be understood, since velocity is derived from user story point estimates and not absolute indicators of productivity. Velocity can be a key element for sprint and release planning and another indicator of overall team performance.