The analogy with physics and basically differential equations brings in familiar concepts from the "spherical cow in vacuum" world. If we wanna go technical, then acceleration too does not matter, cause jerk (acceleration of acceleration) matters even more. We could keep going deeper and deeper into derivatives at no gain. You can introduce mass, air resistance and whatever you want, but at the end of the day this is all just an analogy. Getting into technicalities of jargon has no practical benefit.<p>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 should be a special circle in hell for companies abusing velocity as a metric. Story points are made up points and looking at their velocity or acceleration will result in noise. Managing that noise may look useful, however, it is waste of time. It is as useful as going to the seaside and writing reports on underperforming waves.<p>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.
I know that there are definitions of velocity such as "a measure of the rate at which a development team consistently delivers business value". But I find this definition to be pretty useless in practice, so I ended up landing on a different definition, which is that velocity is "the ability for an engineering team to maintain productivity in the face of changing business requirements".<p>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.
Can't wait for all the physics concepts & lingo to go mainstream into software companies..<p>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..