Keep Velocity in its Lane
Velocity is an extremely popular metric used by many Scrummers to measure team performance. Velocity is the number of points assigned to each backlog item, and each Scrum Team determines how to assign these points. Teams have the freedom to use story points, story size, work duration, or some other factor. The only restriction is that once the point system is established, it must remain consistent. Ultimately, the velocities of completed stories are summed to get the number of points completed by a Scrum team in a Sprint.
This metric is simple to explain and understand; however, some leaders respond to the similarity between velocity and traditional productivity measures. They reason that, like a productivity measure, velocity can be used to manage team and individual productivity. Unfortunately, this just leads to Velocity Hell.
Velocity Hell: Damaged team morale or reputation resulting from attempts to control or compare velocity.
Anthony Amos
Velocity is a lagging indicator, which means it emerges after after activity has occurred. Lagging indicators reflect what has happened, and as anyone in the financial industry will tell you: Past performance is not an indicator of future results. Some managers attempt to make forecasts based on velocity; and in the hands of professionals who understand the risks, limited velocity forecasts can be meaningful. But, teams enter the gates of Velocity Hell when they agree to velocity goals, compare different teams’ velocities, or make long-term commitments based on velocity forecasts.
British Economist Charles Goodhart created this adage when researching monetary policy. He discovered that natural statistical relationships break down when used for regulatory purposes. This is precisely what happens when managers use velocity to influence outcomes.
Velocity’s humble purpose is to objectively quantify the work completed during a Sprint. The definitions of velocity by Scrum.org and Scrum, Inc constrain velocity to use within a team. This metric’s validity comes from this intentional constraint which reflects the strength of the team’s development process and maturity while also raising flags when some aspect of the process or team practice needs attention.
Proper Care and Feeding of Scrum Velocity
Many modern gas-powered vehicles display average gas consumption in miles per gallon (MPG) or kilometers per liter (Km/L). Like velocity, the owner or driver controls any number of factors that influence gas consumption. For instance, our friend Avery buys a new vehicle that consumes an average of 33 MPG (14 Km/L). After one year of driving, Avery discovers that the vehicle now consumes 26 MPG (11 Km/L). This reduced measure tells Avery that something is wrong in this complex system; so Avery takes the car to Morgan, the mechanic.
Morgan informs Avery that the vehicle hasn’t had an oil change in more than a year, the brake pads are unevenly worn, and tire treads are low. After fixing the problems, Morgan tells Avery what processes to change to keep this system running well; including regular oil changes, accelerating gradually, and applying brakes gradually to start and stop more smoothly. If Avery makes these changes, then fuel efficiency will improve, confirming that the changes worked. If Avery ignores Morgan’s advice, gas consumption will worsen and the system will deteriorate to the point of failure.
Teams committed to continuous improvement use velocity to confirm that improvements are working, just as fuel efficiency confirms the benefits of regular maintenance and good driving habits. On the other hand, velocity quickly becomes unreliable when teams set velocity targets, forecast schedules, and compare productivity. These manipulations transform velocity from a metric to a policy, making it subject to further manipulations as a means to satisfy expectations. Continued manipulations will erode stakeholder trust in the team and weaken credibility. Welcome to Velocity Hell.
Velocity’s Purpose in Life
Scrum Team Velocity serves two important purposes:
- To steer work in progress
- To quantify the effects of process improvements
This limited use of velocity will reliably inform Sprint Planning and confirm or refute the impact of process changes. Naturally, teams should improve as the mature. Evidence of improvement becomes apparent through increased velocity. But, such perceived improvement is only reliable when the team commits to an unmanaged velocity.
Velocity manipulation commonly appears as project forecasts in Burn-Down and Burn-Up Charts that extend beyond one or two Sprints. The other side of manipulation occurs by the team itself in response to velocity goals or competition. Doc Norton provides more detailed insight in his excellent post on Velocity Anti-Patterns on DZone.
Three Metrics to the Rescue
High performing Scrum Teams rely on an effective and improving development process. So beyond team velocity, they capture informative metrics that provide insight and support decision-making. Lead Time, Cycle Time, and Throughput tell the team how long it really takes to deliver features. These metrics also make a strong ROI argument for automation and sometimes for more staffing.
