When people say "velocity" they actually refer to all the "derivatives". Just like when I say my car faster, well it is both faster and accelerates faster and all of those things. A Tesla is faster than a normal bicycle. Faster and "velocity" have mental association and that's all it matters. Changing a the term from "velocity" to "acceleration" and whatnot just changes the label, not practical meaning and what people want to convey.
There might not be an acceleration of acceleration... Etc.
So "all the derivatives" doesn't make sense.
Matter is limited by the celerity of light in a vacuum after all...
They typically play a role if you care about how smooth the transitions between two accelerations are (e.g. vehicles)
Similarly designers and engineers look at derivatives of curvature (1/radius) if they want to achieve smooth transitions between curved surfaces (e.g. car bodies).
What is useful, is to understand why certain task take longer than anticipated and learn lessons from that. Were there hidden requirements or was the task too ambitious and should it have been broken down in smaller tasks.
By framing it this way, I find that velocity becomes something that a team can actually experience, at least informally; and it implies the need to put time towards tools, management and architecture, rather than just features.
It isn't even usually this, because typically it's _developers_ - not the wider business - who assign point counts to tasks. At the end of two weeks you've typically done about two weeks of work so all that is actually being measured by velocity are the median numbering preferences of the team. eg People who like "fibonacci numbers" invariably achieve a velocity of about 6 * $DEVELOPER_COUNT per sprint.
In order to get a measure of business value you would have to involve someone who knew the relative value of the tasks. Usually that does not happen and agile has at least partially contributed to that by standardising the idea of a development team as being primarily made up of developers (with one token project manager who is there because they know how to manage people, not because they have special knowledge of business value).
Agile, at least as popularly understood, has moved the whole field backwards by entrenching the separation of developers from non-developers. If you try to work directly with the business on a modern agile team, you tend to get rebuked! You've cut your "project manager" (who typically doubles as your line manager) out of the loop and you're no longer making progress on the agreed team measure of story points. Frustratingly, trying to work on business value is de facto non-compliance on many "agile teams".
That said, while I am no fan of “agile as popularly understood”, my experience suggests you have the causality backward. Agile is simply a term forced on traditional project managers to make the business sound cool. Nothing is different from the way it was before agile, except the meetings have cool names.
In an environment that takes the agile manifesto seriously, working hand in glove with the business is kinda the point. But most businesses haven’t even heard of the manifesto, and those that have … don’t care.
My only hope is the "reduce mass" will serve as a detractor, but I'm sure some slick guy would say "We can use Agile and microservices for that" and then we're back in the hole of tech bs..
