Nevertheless, sometimes it makes sense to get some numbers. It can be used as a signal that something went wrong. Maybe your teammate got family problems or burnout. Anyway, if a programmer usually produces X units of work, but have done only X/2 in the last measured period, it is time to figure out what happened.
I am not a manager, and I use metrics to estimate my own productivity. I often work totally without supervision and my collaboration with customers is only based on trust: “Do what you want to, but get it done.” So I need some metrics for self-control. And I discovered an optimal one (at least it works for me).
Meet the number of unit tests (NOUT). Unit test usually has constant complexity. It is a key feature. And it is obvious, that NOUT grows proportionally with program complexity. So you can measure productivity in NOUT/week or total progress in just NOUT. You can even try to estimate features in NOUT. It seems, it will be more accurate rather than story points. And if you start to pay your programmers for NOUT, they will just improve test coverage (it is a bad advise, don’t do that, they will find out how to fuck you up).
In my opinion, it is still far from perfect. But if it is used with wisdom, it could give you some advantage. If it isn’t, well... see the first paragraph.