Development speed is important, but make sure your primary focus is on the result.
There was a contest where contestants had to find a box in a forest based only on a photograph of an item. There were two contestants. One was a spry young man who has never been to this particular forest. The other was a limping 60 year old woman who has lived nearby and knows these woods like the back of here hand.
The pistol fires and off they go. The young man takes off running. He runs here, runs there, runs circles, looking for something familiar from the photo. His endurance is uncanny and his ability to jump across branches second-to-none.
The lady looks at the photo and studies it. After a few minutes, she takes her walking stick and limps off. She recognized the rocks in the photo and knows more or less where to go to find the box.
The young man is much more productive in “miles ran per hour”, or “acres searched”, or in “O2-consumption-per-mile” metrics. For the lady, the above metrics are dismal.
However, she beats the man in the most important metric: “boxes found”.
It’s tempting to track how much work your team is putting out. Your team could be writing the most lines of code (“miles ran per hours”), or closing the most defects (“acres searched”), or deploying the most stories (“O2-consumption-per-mile”). But if those changes don’t affect the one metric that matters (“boxes found”), then you may want to reconsider what metrics are worth tracking.