Is Sprint Velocity meaningful?

Velocity can be one useful input and empirical piece of data to assist a team with forecasting how much work can be completed, so some Scrum teams find it useful for Sprint Planning. Release forecasts could also be derived using velocity. 

The goal of velocity is not to be increased each Sprint. That just results in bad things happening, such as cutting corners.

Scrum is lightweight, intentionally incomplete, and doesn't mandate the use of velocity. In fact, it isn't even mentioned in the Scrum Guide. Some teams choose predictive forecasting methods, which include throughput, scatter plot probabilities, and monte carlo forecasting.

The analogy doesn't resonate with me, to be honest. Comparing complex work compared to taking a trip is much different.

Scrum on!

It can be meaningful to those doing the work driving, and who are accountable for the quality of what they are doing, including the safety of those around them.

Passengers who demand "faster, faster!" are not accountable, but they nevertheless pay a heavy price for calamity, and so are wise to let the driver choose a safe velocity for them. The speed they crave will indeed prove meaningless, when upon arrival nothing is done or delivered, assuming they arrive anywhere at all.

Chris,

I think the point of the analogy is that there are endless random paths to get from point A to point B. There isn't anyway to ensure that any next random path will be faster than a previous one. The number tickets in a Sprint are random, Story Points are random estimates, the backend going down during development is random. Developer's skill and domain knowledge is essentially random. If that is the interpretation of the analogy, then I don't see how management can insist on Velocity to be ever increasing. Not mention taken to its logical conclusion, eventually Velocity will be infinity.

I also agree with Ian, that faster isn't better. Plus, engineering "could" always game the system when estimating Story Points. I have always felt that management wants software development to behave like and be as predictable as, a factory assembly line. It just isn't going to happen.

In my experience a lot of the validity depends on what you are using to measure Velocity.  If you are using Story Points, my believe is that is a useless endeavor.  As you said, Story Points could be random.  They are an estimate (also known as a guess) made at a specific point in time based upon the information you had available.  As soon as new information is gained, that original guess is no longer valid. 

However, as @Chris points out, if you are using some other metric to determine "velocity" it can be useful.  For example, cycle time or throughput have always been good choices for my teams.  They are based upon the actual time expended and are more accurate than depending on guesses.  However, velocity is only useful for the team that is responsible for the work.  And every team will be different.  Velocity can be useful for determining if a selected body of work can be completed during a specified duration of time.  But that is all it is useful for and it is not a certainty.  To use the travel analogy, even if you use the same path every time, the times to complete the travel could vary because of weather, road conditions, other drivers on the road, and even the need to stop for fuel or biologic breaks. But you can have a fairly good idea of the time it will take if you make the trip enough times and do the math.

@Ian has a great point.  Constantly trying to increase speed is going to lead to problems.  There is nothing in any of the agile practices that I know where the goal is to constantly be faster.  In all of them that I have ever encountered, being consistent is more important than being faster each time.  You want to reach a sustainable pace of delivering value.  That leads to better predictability, less burn out, consistent code quality.  It is much safer and a better option for any organization.

Thank you for your thoughts Daniel, I agree.