This post is inspired by an article from Gojko Adzic titled The Play, the points, and the biggest lie in software.
In that piece, Gojko talks about how Story Points are really just a huge lie, which doesn't only hinder progress, but also creates all the wrong incentives, fuelling complexity in software and driving us to build more for no good reason.
It doesn't incentivise (or even discourages) removing features from software, dooming it for rapidly and infinitely increasing complexity. After all, if we're paid for "delivering points" and we do that by adding more features and writing more code, what does removing code mean? We un-deliver points that way? It may sounds stupid when put in writing, but the brain is a simple machine built around generalisations and it makes connections like that, whether you want it to or not.
That's something I observe in regards to tests. People say "we're paid for delivering features, not for writing tests". Yeah, there's some truth to that, but you're actually paid for delivering features that work, fulfil a need, and don't take the whole system down. But we don't think of it that way, really. The brain is a lazy SOB. It's the most energy hungry component in your body and it tries hard to optimise that energy usage, so if you build an incentive system around getting as much code to production as fast as possible, that's exactly what you'll get. If you cut that path short by defining delivered as "dev ready" aka "in QA", then that's again exactly what you'll get - an avalanche of crap piling up in front of QA, creating all kinds of waste in TPS terms.
The bottom line is, if you want to measure anything, keep in mind that your measurements will inevitably (consciously or not) become goals and that, once they do, people will cheat. So choose your measures wisely. And, more importantly, evaluate periodically what these metrics do to the brains of the people affected by them.
Some metrics I use internally - as in, within my brain to hopefully force it to do the right thing - is minimising the time from idea inception to idea validation and minimising the necessity for debugging. I find both of them to help me reduce the same kinds of waste that story points, and all the other "stuff per unit of time" measurements produce. They drive simplicity and are very well supported by practices such as TDD and CD. They also land nicely in the context of Lean... in general. But this isn’t universal and different brains may find different ways to derail these definitions.
The interesting thing to notice here, by the way, is that while story points are aimed at maximising something, the metrics I use and/or promote are almost always based on minimising. Less debugging, less merging, shorter feedback loops. The reason for that is simple, and it's probably the most important lesson from Lean: if you minimise waste and ex post facto quality assurance, both quality and quantity follow. If you aim at just maximising quantity, quality is doomed by definition, for the reason I wrote above - our brains love shortcuts, and crap is easier to make than craft. Literally and figuratively.
As a final thought, this also works nicely with the idea of "code as a liability". In that context, if we translate "story points" into "features" and "features" into "code", we can then translate "we delivered 20 story points" into "we became measurably more liable". Which no longer sounds so snazzy...