Hit rate
That is the actual story points achieved in the sprint divided by the commited/forecasted story points.Example: You commited 52 story points, but you have only achieved 37. Your hit rate is 71%.
Bugs per sprint + their average lead time
Track how many bugs are opened for your team/product per sprint. The idea is: the less bugs arise, the higher the quality of your software and the less you are sidetracked by bugfixing. Naturally this indicator works best if you fix bugs instantly and don't collect them in a bugtracker.Also: track the average lead time it takes to fix bugs. The less time it consumes, the less you are sidetracked. Try adding a policy for this (for example: "We try to fix every bug in 24 hours").
Impediments per sprint + their average lead time
Track how many impediments arise per sprint and their average lead time. The less things you have, that impede you, the more productive you should be. Also: the faster you can remove these impediments, the higher your productivity should be.Amount of overtime / crunch time
We were a bit unsure about this one. How much does it really say about productivity? In my opinion you should only do overtime in absolutely exceptional situations. In my opinion if you need overtime (or crunch time) there is something fundamentally flawed in the way you do your work. My theory is, that overtime is taken when planning badly. This can be either because you (constantly) plan too much and/or there are way too few people to do the work you want to be done. If you want to track this, make sure that people are able to provide their overhours anonymously.
Reuse rate
One thing we were completely unsure about is the reuse rate (how many of your code is getting reused?). The idea was that the less you reinvent the wheel over and over again, the more productive you should be. But how to track this? The only things we came up with was to run c&p-detection/duplicate-code-detection. Is this a valid metric in this case? What if you have multiple projects? If you have any ideas for this one, please let me know in the comments.
Don't: Velocity
Don't use your velocity as an indicator for productivity. First it is very easy to manipulate and chances are about 99% that it will be. Second every team has its own velocity, meaning there is no qualitative information about productivity to be found here.
So far we haven't tested these metrics yet as indicators for productivity. If we should start to do so, I will gladly let you know about any outcomes. If you should have any more ideas on how to measure productivity, please let me know in the comments below.
