Get certified - Transform your world of work today


Velocity Versus Quality: Trade-off, Balance, or Win-Win?

Agile metrics

25 October 2017

Ramkumar Arumugam
Cognizant Technology Solutions India Pvt Ltd

Agile software development teams should strive to develop high-quality products. The need to cut corners to deliver more features (increased velocity) is attributable to factors such as faster time to market, launching ahead of competition, or delivering functionalities more frequently for customers. Bob Galen once said, "Agile isn’t a speed play. If you play the game with integrity, passion, and balance, it can become an awesome speed play. But it (speed) isn’t free."


Releases can be made frequently from the extra capacity gained through continuous integration and development (tools adoption); thus, increasing velocity or quality can be increased by paying down technical debt and fixing defects and stability issues with the product.

Michael "Doc" Norton, author of Escape Velocity, talks about three laws that influenced him while he was looking into Agile metrics.
  1. The Hawthorne Effect – Something that is measured will improve, at a cost.
  2. Goodhart’s Law – When a measure becomes a target, it becomes a good measure.
  3. Freidman’s Thermostat – Correlation is not causation.
Velocity at times can be a risky measure to set as a target. Velocity is nothing but the number of accepted story points turned over by the team in an iteration. This metric may be misleading to management, as they may very well say, "Well, we have completed 10 story points this sprint; let’s target 15 story points next sprint."

As you can see from the above graphs, velocity over a period remains constant with the team’s evolution. It cannot be increased beyond a certain threshold without extending the iteration or compromising on quality. Velocity can be increased to release more features by reducing quality and by finding issues later and fixing them.

Quality can be increased to hold features for a longer period for testing and improvement. Companies will do beta testing for a longer period to increase the quality of the product before moving to high quality. Organizations set multiple releases such as alpha, beta, and full releases with different quality standards. They know when to adjust, and if they switch too late, they will reduce the time to market. If they switch too early, they may stall development. Economists call this "economic frontiers," as the product or feature can be inside the line with the worst quality/velocity and can lower velocity when there is a demand for higher quality.


Though there is lot of bias toward increasing velocity in every iteration (release more features faster), if there is no attention to quality, the system will soon become fragile and will not be able to sustain future scope changes. The best way to confront this problem is to balance feature developments with refactoring and fixing technical debts wherever possible. This will reduce the velocity in developing new features but will pay off in the longer run.

There is no benchmark or standard story points split between new feature development and quality improvement process. The team can negotiate with the product owner to identify appropriate story points for improving the quality of the software and accommodating new features for the iteration. Many experts have given ideas on the balance between quality and velocity and have also suggested ways to improve both velocity and quality. Product owners often decide on balancing the need for quality and the desire for velocity.


There is a tendency to cut corners and release more features often. Compromising on quality may offer short-term gain but will come with its own disincentives with time spent refactoring and time spent fixing defects. It is like trading time now for later, and later comes with compound interest from putting off the work. Following are some of the symptoms of low-quality software:
  • Recurring defects
  • Slow system performance
  • High technical debt
  • Unmotivated team
Teams should be able to write good-quality code that will help them ship more features. There is no single silver bullet that can increase both quality and velocity.

The long-term solution is to improve the overall development process to have higher quality at every velocity. Adhering to coding standards, refactoring mercilessly, designing simply, paying down technical debt, developing applications rapidly through continuous integration and continuous development, and robust testing coverage will limit the number of defects in the product and increase quality. Automation of test suites (regression) can also play a better role in shortening the cycle times by increasing the velocity and quality.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.5 (4 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up