The longer I am concerned with stats and machine-learning, the more wary I get of what I like to call tea leaf reading, i.e. substantiating arguments with numbers. The problem about this is mostly, that the evidence is kind of arbitray. Without too much effort, someone could come up with a counterargument substantiated by some other numbers found in the same context. Truth is, most systems are really complex, and quite often, it would take substantial efforts to produce numerical evidence for or against an argument, that would hold up to statistical scrutiny. And even professions, that were well aware of basic stats, such as sociology and psychology, have recently learned how challenging empirical evidence can be.

So, when I read the Scrum Guide, which emphasizes several times how empirical the method is, the alarm bells are starting to chime. I know, some Scrum consultant will use this, to advice people to track their velocities and base decisions based upon it. Yet many changes of velocity might just well be within the range of usual fluctuation of that quantity. Scrum teams evaluating whether an action they undertook is effective or not based on their velocity, are reading tea leaves. Roughly speaking I belief that you can use a velocity measurement (I would prefer throughput as a metric) as a guide for estimating when a backlog item might be implemented, plus minus an error margin. I also belief that the quantity by itself is so volatile and depends on many parameters PLUS is highly stochastic (meaning, even if the circumstances and parameters do not change, by coincidence, the team would take more or less time to complete comparable work items), that it isn’t of much use for much.

Much more useful in my opinion is in many cases a conceptual, deductive argument, and yes, personal experience and narrative – that is unless I am very sure, that a sound empirical reasoning can be made.