In our opinion, there are 5 types of metrics that you can find in your software delivery:

Speed is always a measure of time, usually an average.
​
​Lead Time is a good example of a metric that tells you how fast you're moving from starting to work on code to releasing it in production. 

Volume (or Quantity) helps you understand how much was done. 

Volume is a difficult metric because a single unit of work, for example a pull request or a review, can not be compared to one another. It can be that a 1 line bug fix was highly complex and took 10 hours, while 500 lines of code were easily added to a low risk/complexity component. But without aggregate volumes it is hard to understand the other type of metrics. 

As an example, if my Lead Time is 5 hours on average for 3 pull requests, that doesn't tell me much about the speed of our team, but if it is 5 hours for 300 pull requests, it starts painting a picture.  

Volume is also important to be able to understand your processes, for example, if a team releases 100 Pull Requests in a sprint and I see that only 20 were reviewed, volume is again important to help me understand how we work.

Engagement is a measure of how many contributors are involved. 

My favorite example is a growing team, as we add additional members to the team, does our volume of work increase while maintaining the same speed and quality? These are the kind of questions that can only be answered by knowing how many contributors were active during a period.  

Quality is a metric that needs to be proxied by metrics like # of bugs that give an indication of the quality of the software delivered. Quality metrics should be as close as possible to the end-user experience of your software.

Without quality metrics, it is easy to find yourself going at a faster speed, or increasing volume but if that is at the sake of delivering a worse user experience to your end-users, it is usually not worth it.

Impact

Impact measures the business goals we had for the software we are delivering. 

Often when we are building software it is easy to be removed from the business objectives it is meant to improve. For instance, refactoring a major component without changing its behavior, how does that really relate to our end user? Other times we are delivering a new feature in an application, for example, the ability to buy a book online with 1 click instead of 4, that can clearly map to the business objectives.

Impact is sometimes hard to measure, but when you can, it helps align everyone.

In the current version of our product you'll find a lot of metrics and charts that touch upon Speed, Volume, Quality, and Engagement. You can request specific metrics and track our progress over at product.athenian.com where we share our roadmap and allow users to submit and upvote feature requests.