I have a problem with this premise: > Velocity metrics are as loathsome as the horoscope because neither provides any insight on why something went wrong or ho

I have a problem with this premise: > Velocity metrics are as loathsome as the horoscope because neither provides any insight on why something went wrong or how to fix it. Specifically, it assumes that there is that one metric out there than can answer the “why” and “how” questions. In reality there is none, even your proposed CFD (which I use myself) doesn’t really answer them. Instead what these metrics do is answer the “what” question. Specifically, they signal to the team that something is wrong and they need to dig deeper to get to the bottom of it before arriving at a solution. In fact, one of your examples skips this very important step: > A manager who wishes to make their team’s cycle times more uniform can try matching the rate at which tasks enter the system to the rate at which they leave. How did the manager know that this was the correct solution. Perhaps they went further, asked questions, and maybe even consulted stakeholders instead of just looking at the CFD and go “Ah! I will control the arrival rate!” This would’ve been the same with burnup/down charts provided that the user of these charts knows the probabilistic nature of these metrics. In the end, it’s not the charts/metrics that matter the most but the person interpreting them.