The whole point of scrum/agile/etc... is to work with imperfect humans. And estimation is a very hard process which is also involves ego and self-worth. So maybe in your team, if asked to estimate in days, Person A would always say: "I am a star programmer! I can do it in 3 days! No, even better, I can do it in 2 days!" .. and once its time to implement it will take 1-2 weeks. And maybe person B would have imposter syndrome and be always saying: "oh, I am not sure.. this sure sounds hard.. maybe 2 weeks? oh maybe make it 4 weeks just to make sure..." for the tasks it'd take them 2 days to implement.
As a manager/lead, how do you deal with this during the planning time? If you are talking in days, and saying to Person A: "No, you always underestimate, I think I will write a week there", then person A will feel insulted that their star-ness is challenged, and will either fight back or or be loudly unhappy. And person B would similarly feel stressed when their estimates are cut. And what if they share their estimates with people outside of their teams, who have no idea about their conversion factors? That would be even more misleading.
That's why there are points. They are simple and much less controversial. Saying "Person A, this task seems to be big, let's make it 5 points" is much nicer than saying "Person A, I don't think you can do this task in 2 days, you'll need at least a week". If a person A brags to random customer: "I've started on a task and I think it's a 2-point one" it will not prompt awkward questions like "hey, a week has passed, is task done yet?". And "our team velocity is lower than usual this sprint" sounds loads better than "you should never trust person A's time estimates"
So points make plenty of sense in real world with imperfect people, and thus "how many points do we do per sprint" is also a valid question. And I don't see why not call this "point velocity", it does kinda matches the use of "velocity" in English.
Note: the literal "improve velocity in points/sprint" is bad idea of course.. but then the question is how did you end up with such KPI? If this was given "from above", then I see no problem with taking it at a face value: "We are going to increase our points/sprint by 5% each sprint, and will reindex our tasks accordingly. By the end of year, I expect we'd estimate 1-day tasks at 3 points".
The part I attempted to highlight as nonsense, perhaps unsuccessfully so, is the idea that “velocity” is a measurement of output. It is solely a measurement of estimation accuracy. As such, your example of increasing velocity by 5% each sprint falls into the three problematic scenarios described, right? If not, I’m happy to learn what I’m missing.
As far as the usefulness of story points to talk about time estimates while mitigating some of the human nature you describe, I don’t disagree. However, by masking that points ultimately are placeholders for time, I believe it’s contributed to nonsensical concepts (like Velocity) which would be clear if using plain language.
Absolute & utter nonsense.
I worked on a project that usually had two week sprints, part of a sprint was running a batch job that took two days to build a database and machine learning model. It took more like 2 hours of labor to set up, but if you put off building the database as late as possible as everyone else on the team seemed to do, you could easily put it off until the last day in which case you blow the sprint. If I did it, I would start it very early (at least a week) because there was some possibility the job would crash or you found it was configured wrong.
Thus I learned there was a big difference between calendar time (complete the foundation of the the building by Feb 1 so the very expensive crane that arrives on Feb 1 c an go to work) and punchclock time (pay workers for 2500 hours of labor to build the foundation.)
