The post gets one idea right (velocity represents quality of estimation) but completely misses at all other points, and it incorrectly calls everything "nonsense".<p>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.<p>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.<p>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"<p>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.<p>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".