But you know it’s not the “right” thing to do in an agile perspective: velocity is a measure of a team’s reality, the means for estimating the next sprint, then adjusted to serve the next after that, and so on.
That said, velocity should never be a pursuit, but the pace of your team while producing autonomously and responsibly and is only valid for the given team and given tasks (as estimating with points makes those estimates that team’s thing). A better pursuit should be that for a sustainable work pace, so you only ship the best software as enabled by a healthy work routine.
I know lots of said “agile” teams are on the former, trying to increase velocity, but that’s like trying to slow time for anyone else. Or, if they get the impression that it works (velocity is increasing), it’s one of three causes: estimates are done poorly; developers working lazily at previous sprints; too many impediments on the beginning of the project (where some backlog re-prioritization could come in handy).
And for those teams, they don’t actually value the agile principles, but are actually re-targeting their cult of the process for waterfall to agile methods. I mean, you rather throw away the process manuals than give up basing your work on the principles that enabled it in the first place.