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

Last updated Apr 16, 2024 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 between velocity and value. On one hand, the way the author depicts the chasing for speed rather than added value is surrounded by examples that he might have faced in 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 progresses 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 are some details on the understanding of what delivery means for each one of them. Besides that, Doc dives a bit on what “code quality means” from two angles: code complexity and code coverage. This is a mixed-feelings terrain with many discussions among practitioners and academics.

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

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 ifs and he refactor that to use a strategy pattern, which can be a metric 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 an entry point for anyone who would like to know what metrics can be used in a team beyond story points.

References

[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.”