Should "sprint velocity" be "sprint speed" instead?
To start with, let me clarify that I fully understand that sprint velocity is not part of the scrum framework.
In physics, velocity is a vector that shows the direction and magnitude of the change in an object's position. At the same time, speed is only a magnitude of a change. From this point of view, sprint velocity is not velocity, it is speed.
Using physics terminology, direction is an objective that is provided by the product owner, speed is the number of story points that the team can complete, and goal is the actual velocity of the sprint—the position where the team wants to be by the end of the sprint.
The sprint velocity concept sounds wrong, starting with the name itself, not talking about other questionable traits it has.
In Scrum, a team ought to be able to turn on a dime between Sprints. The work is complex and emergent and any forecasts we make ought to be predictable rather than predictive. Goals ought to be seen in that light...they principally lend a coherence from which direction may be inferred.
Velocity is the rate at which work is Done. That's the target which counts and the commitment which is abused. The actual Sprint velocity of too many teams is zero, zip, nada, nothing.
It's a discussion about meaning of words in physics and dictionary
Like we measure force in Newtons, but when we talk about "deadly force", or " force of nature" or "Russian forces attack Bahamut" we aren't necessarily measuring them as kg⋅m/s2
If this was a scientific discussion, I would say that your theory is flawed because of this one statement
...speed is the number of story points that the team can complete,...
Story points do not represent anything other than a guess about relative effort made by the Developers based upon information that they had at the time they made that guess. If you want to measure the speed at which the work is done then you would better served by looking at flow metrics like throughput or cycle time. Those are actual measures of work being discovered, work beginning and work ending.
You picked one definition of velocity for your premise. But what about other definitions like these from Merriam-Webster? (https://www.merriam-webster.com/dictionary/velocity) I particularly like 3a
3 a : rate of occurrence or action : RAPIDITY
Notice that it has nothing to do with speed. It is characterized by being rapid. And rapid is defined as
: marked by a fast rate of motion, activity, succession, or occurrence
This is what would be measured by velocity in an agile team. Why? Because look at the definitions of "agile". (https://www.merriam-webster.com/dictionary/agile)
1 : marked by ready ability to move with quick easy grace
an agile dancer
2 : having a quick resourceful and adaptable character
an agile mind
Scrum, like all agile practices, have nothing do to with being faster. It is about being able to adapt quickly and efficiently to changes. If you focus on going fast, you often sacrifice the ability to change course if something unexpected occurs.
"Story points do not represent anything "
That's something Scrum guide should possibly include.
It is beyond imagination how many recruiters, employers, managers and even Scrum masters dont understand that SP are imaginary estimations and thinking that story points are some exact measurement like meters, kilograms, pounds, megabites or amperes.
Agree that velocity as a term can be problematic. That said, I don't think that "Sprint speed" is an improvement on "Sprint velocity". Speed is irrelevant if you are going in the wrong direction and speed isn't really the goal. Achieving goals and delivering value is the goal.
velocity is a vector that shows the direction and magnitude of the change in an object's position
I will say that with this definition, velocity at least includes direction (Sprint Goal), and measuring the magnitude of change or progress towards that direction (Done PBIs that support Sprint Goal).
Scrum.org supplies its own definition of velocity in the glossary, which seems sufficient…
Velocity: an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.
Interestingly story points arent even mentioned in the Scrum glossary mentioned above
@Nicholas, that is because User Stories, Story Points are not part of the Scrum framework. User Stories started at a company named Connextra when their eXtreme Programming teams wanted to use the "story" concept that Kent Beck had created. They added the format "As a ... I want to ... so that..." as a way of standardizing the process and added the word "user" in front of "story" to show the perspective that was being used to create their "user story". User Stories are not a Scrum artifact at all so the Scrum Guide will have no guidance on how you choose to use them.
The Scrum Guide never mentions them. It only mentions Product Backlog Items and never specifies how they should be composed. That detail is entirely up to the team to decide. Some choose User Stories, others do not. And from my experience, the ones that do not have an easier time being productive because they do not get hung up in the details of how to write a story correctly, what do Story Points mean, what do we do with defects, how do we manage epics, etc. However, I have seen teams that work more in line with eXtreme Programming concepts be very successful with them.
There are a large number of posts on these forums asking for help because they can't understand how to do something with User Stories, Story Points or velocity measured by Story Points.