Seen exactly the same, sadly not just in one shop. Half completed stories would be split into part 1,2,3, or worse: renamed to "Attempt to implement...", just to make the burndown chart align at closure of sprint and give people the pleasure of dragging items to the done-column. Didn't get better when some higher up scrum master once had the brilliant idea that all stories should be max 2 story point large, otherwise need to be refined further. Together with a company-wide policy that a story point is roughly equal to one day, for all teams, because it made the high level jira dashboards easier to aggregate.
Not sure what it was meant for, since with this practice it would tautologically just show headcount * days in a sprint. More like time reporting rather than measure of progress.
The beautiful thing is there is a built into Scrum solution to this.
You alter estimation.
The fact story points are made up BS numbers means developers have full control over the velocity chart.
My favorite part of Scrum is it makes it IMPOSSIBLE to track velocity.
By making velocity IMPOSSIBLE to track, management MUST pivot to OKR lead management.
And OKR lead management is by far the best approach to software development.
If your estimates are too crazy, you are forced to break them down into smaller tasks. This means lots of meetings. I think most engineers would rather have a bad estimate and "face the consequences" (generally not much), rather than put up with more meetings.
Can you describe "OKR lead management"? I am familiar with OKRs.
I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.