Welcome to Scrum Velocity Hell 

 March 4, 2021

By  Anthony Amos

Velocity can be a deal with the devil
Image by StoryBlocks

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.

Goodhart's Law
Image by Anthony Software Group

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.

Image by Anthony Software Group

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:

  1. To steer work in progress
  2. 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.

Anthony Amos

Anthony started creating software in 1981 when he curiously picked up the programming manual for a Wang OIS Word Processor while deployed with the US Navy. He had never seen a computer before, but he taught himself how to write programs that made his Navy work easier and more accurate.
After his honorable discharge in 1986, he began creating financial and analytical software for diverse organizations including Verizon Wireless, JP Morgan Asset Management, GoldenTree Asset Management, NASDAQ, Prudential Insurance, AT&T Capital Corporation, Lehman Brothers, Ernst & Young, and Blue Cross & Blue Shield of New Jersey.

Demonstrating his commitment to the principles and values of Agile Software Engineering, Anthony is a recognized SAFe® version 5 Program Consultant and holds many of the most challenging and difficult to attain Agile certifications. His practice is grounded in Agile Frameworks as he leads clients to implement Scrum, Kanban, Scrum with Kanban, Scaled Scrum with Nexus, and Scaled Agile Framework. He believes in using the framework that best fits the organization's cultural and business direction while maintaining disciplined processes.

Tony Amos

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!