Yeah, it's crazy how common that view seems to be in the industry for something that simply does not make sense.
What people call "velocity" is an inherently relative measure, but they insist on treating it as an absolute. You can have a really slow team have a "great" velocity if their estimates account for moving slowly, and a fast team have awful "velocity" if their estimates are too short.
Ultimately, it's a measure of something like predictability or consistency. Treating it as if it actually measures development speed is a category error.
And hey, maybe consistency is what you want to prioritize over everything else! But, well, probably not.
i love it when product sets requirements and milestones and then leadership says "what if we try this thing" in the middle of the work but then doesn't give additional time for experimentation. then when the deadline comes around it's engineering's fault.
Ideally, you have enough handle on the schedule that you can approximate the schedule cost, and present them with the option. Example:
ENG LEAD: I can add that experimentation to the Gantt chart, but normally any new ask will push out other things.
BIZ PERSON: Can we do it without slipping our next MVP milestone? It would help with a sales prospect, but isn't worth slipping.
ENG LEAD: OK, since you want it in a week, to minimize impact to the MVP schedule, I can task Jimmy 90% on it. Plus myself 20%, to mentor and keep this on the right track, while Jimmy gets up to speed. We just heard that other customer pilot project was canceled, so I can probably shuffle those resources towards the experiment, without slipping MVP. OK?
BIZ PERSON: Sounds good.
(Of course, if the business people are bad at business, this can go wrong...)
BAD BIZ PERSON: Isn't Jimmy a junior engineer? This experiment is my best drug-fueled mindfulness epiphany yet, and needs the best engineers.
ENG LEAD: If this were key for the MVP, without time for anyone to ramp up their skills, I'd normally plan for Jane or Bob to do it. But interrupting their current immersed critical path MVP work for even a couple days now would probably throw them off for calendar weeks, and likely result in a poorer solution too. And that would end up blocking half a dozen other people for a couple calendar weeks, and they'd only be able to work on lower-priority things. Which would be a immediate 2-week hit to the MVP milestone, plus, worse, a hit to morale of everyone, which would slow us and introduce more risk, just as we're entering the aggressive MVP final stretch where we need everyone rising to do their best work. So I recommend Jimmy, with me working closely with him.
BAD BIZ PERSON: Sounds like this needs my charisma to inspire Jane and Bob to squeeze this in without slipping the schedule.
ENG LEAD: They're already hyper-motivated, on a great path towards MVP, and are operating at peak efficiency. This is an almost mythical moment of greatness, rarely attained by any company, and is startup-defining magic, which will not only make our successful MVP possible, but will also become an instant company-internal legend, setting our engineering and product culture to achieve greatness, for years. If we broke that now, we'd be the world's greatest imbeciles.
BAD BIZ PERSON: Great, the rest of this week, let's do a company stand down for team-building retreat, where I can have 100% of their attention, to leadership them. That will increase their velocity, and we can do the experiment without slipping the schedule.
ENG MANAGER: I should've just said yes, without giving implementation detail, rationale, or tradeoffs.
BAD BIZ PERSON: Jane and Bob can also work on the experiment in the evenings during the retreat, from their tents, after each day of Executive Forest Survival(tm) zip line trust falls. Bam. More time saved. Now go do your magic, buddy! [flashes best confident smile]
velocity is a vector. ICs may bear some responsibility for its magnitude but direction is straight from the top baby