Escape velocity, better metrics for agile teams - Review (Lead time, Delivery frequency, Cycle time, Cumulative Flow Diagram, Code quality, Team joy and Forecasting)

Published Oct 31, 2022

The content here is under the Attribution 4.0 International (CC BY 4.0) license

As opinionated as it can be Escape velocity gives some insights on metrics that can be used in “agile” (whatever agile means in a given context) teams.

From the start a distinction is made from velocity and value. On one hand, the way the author depicts the chasing for speed rather than added value is surrounded by his examples that he might have faced in the real life, while on the other hand, he also makes clear that story points are relative to a given context and that the team can also game this metric (as any other).

As the book progress to alternatives to only “velocity” (meaning how many story points were achieved), alternatives are shared with the reader, such as:

  • Lead time
  • Delivery frequency
  • Cycle time
  • Cumulative Flow Diagram
  • Code quality
  • Team joy
  • Forecasting

Lead time is also present in the famous book “accelerate” published in 2018, Delivery frequency is close to the “Deployment frequency” as well but there is some details on the understanding of what delivery means for each one of them.

Besides that, Doc dive a bit on what “code quality means” from two angles: code complexity and code coverage. This is a mix feelings terrain with many discussion among practitioners and academics.

Nevertheless, Doc concludes that code complexity is directly related to the amount of lines that a given code has, leading to the metrics that many lines of code is a signal of poor quality. Even though on page 118 he recognizes that this is a failed metrics by itself as he also claim:

Didn’t we learn this was wrong in the 1970’s?

I am advocating for it.

The argument used is a simple generalization of a piece of code that uses many if’s and he refactor that to use a strategy pattern, which can be a metrics for this specific case, but can we generalize that?

The other metrics mentioned by Doc are metrics that hopefully might help teams that are stuck on the scrum framework[1] and in love with X story points delivered but no value added.

All in all the book is in my understanding a entry point for anyone that would like to know what metrics can be used in a team beyond story points.


  1. [1]M. Cohn, Succeeding with agile: software development using Scrum. Pearson Education, 2010.
  • Story Points Revisited - “I like to say that I may have invented story points, and if I did, I’m sorry now. Let’s explore my current thinking on story points. At least one of us is interested in what I think.”