If you're competing within the team to complete as many story points as possible that's pretty weird. Is someone using story points as a metric of anything other than forecasting?

But assuming that everyone cares about quality (I know, a big leap), what has worked for me is: tagging stories as bugs/regressions/customer-found-this and reporting on time spent. If you're spending too much time fixing bugs, then you need to do something about it. New bugs in newly written code are faster to fix, so you should be able to show that bug bashes make that number going down quarter over quarter which contributes to velocity going up.

Alternately (and not scrum specific) I've had success connecting a CSM/support liaison to every team. Doesn't give you a full bug bash, but even one outside person click testing for 20m here and there gets you much of the benefit (and their incentives align more closely with QA).

Solution: don't measure story points

It wasn't perfect, but it worked well.

Granted, it required a very specific management, devs with the right mindset and constraints on the kind of projects that could be done (anything customer facing with a tight deadline was off for instance. We used that for the internal infra). So I don't see how you would build a plane at Boing with scrum for instance. Or anything that require very tight coupling af many teams (or hardware).

But for us (60 devs in a company of 200), Saas, it worked great.