Don’t do this. You’re not going to like this, but you’re missing the point of story card sizing. It’s NOT to measure productivity. It’s to measure relative complexity of work. These are not the same thing, and never will be. See, there’s a fuzzy correlation between requirement complexity and time to completion, but that’s ALL that it is. Your goal should not be to measure productivity at such a fine grain level. Rather, measure that you’re getting a few more points done per iteration, until you can’t any more (you start missing commitments). At that point, you’ve reached a hard bottleneck, and your retrospectives should tell you what that bottleneck is. Then, you can either clear the bottleneck (if it’s in your control), or you can raise it to your management as something they need to clear (or not, if they’re happy with the business value delivery rate you’re achieving).

The point is gradual improvement over time until you reach a definable bottleneck, not some arbitrary measure of productivity. This is knowledge work, not bolt turning. How do you measure the productivity of a doctor, or a lawyer, or a marketing department? You can measure some things, but they’re REALLY high level and incomplete/misleading (like number of patients treated per month for doctors, or number of trials attended by year for a lawyer, or measurable market upturn after a campaign vs. cost of the campaign for a marketing department). Programming is more or less the same. The smart play is to “get more done over time”, not try to define what “more” means precisely.