When readers find that I only recommend two metrics to be common across all teams, they will either be excited or disappointed, both for reasons covered in the material.
Healthy uses of team-level process metrics are called out in the Goals section of the entry:
Help teams cultivate an understanding of their capacity for delivery.
Serve as one point of information for leadership to see which teams need help; the type of help will be determined through conversation with a team to understand the context of their challenges.
For now, I have only documented the two core metrics common across all teams. As I begin to flesh out the Continuous Process category, I'll add in the additional metrics that apply to those systems like Lead Time, Cycle Time, etc.
I'll leave you with one last excerpt from the final section titled "A Cautionary Note on Metrics":
The key mistake I see in development process metrics is treating the available data as being far more meaningful than it actually is. Because the measurement, analysis, and visualization of data is such an established practice in business, creating metrics on that data takes very little effort. It seems logical that we would create all manner of graphs and interpretations of data.
However, the accuracy of story points and task hours is deliberately constrained, because it models the degree of accuracy in software development estimation, which is directional at best. Applying overly-granular statistical analyses to this type of data leads to false conclusions and interpretations, not only failing to add value, but actually subtracting value by creating overhead and providing misinformation.
Never lose sight of the intentionally minimalist nature of effective development process. The goal is to create just enough structure to enable teams to be effective, and to not go further than that. The rest of the emotional and intellectual bandwidth of teams should be kept free to focus on creating the best possible outcomes for the products we deliver.