Read on Twitter
Wanted to share my thoughts on the 5 types of metrics I believe you need as a software engineering team to know if you're continuously improving:
• Speed
• Volume
• Engagement
• Quality
• Impact
Thread
• Speed
• Volume
• Engagement
• Quality
• Impact
Thread
Speed 
tells us the avg. time spent on work. Personally I am a big believer of Lead Time (from starting work to it being released in production) and breaking down the average time spent in each step of your software delivery pipeline (e.g. avg time to review/merge/release)
Volume tells us how much work has been done. We like to look at things like # of pull requests, # of reviews, # releases. This is a tricky metric on its own because we know that for example not every equal sized PR or review is the same amount of effort.
Engagement tells us how many people were involved. A feature that was released in 5 days with 15 PRs and 4 people involved starts painting a more complete picture. I think you're starting to see where I am getting too, a single metric without context of others is useless.
Quality , is a difficult one, how do you know if you delivered high quality software. I don't think anyone has the perfect answer to this but there is a proxy I personally like, and that is the # of bugs that are caught at each stage of your software delivery pipeline.
For instance if I look at that feature we released that took 5 days, 15 PRs and involved 4 people how do we know it's of higher quality then another feature with similar metrics? We can look at where we caught the bugs before shipping it to our users. How many bugs did we find...
and resolve before we went to staging, and more importantly to production? The number of post release bugs can be broken down even further, how many were customer impacting / facing? And this brings me to our last type of metric:
Impact. When we deliver software it's for our users and more often that not we have user impacting goals associated with them. Impact to me, while sometimes hard to quantify are the metrics that help us determine if the software we released had a positive impact.
E.g. This new feature made the application 50% faster -> leading to 5% increase in revenue
At http://athenian.co we're working really hard on bringing all these metrics in one place. But remember metrics alone aren't good enough unless you can make them actionable.
At http://athenian.co we're working really hard on bringing all these metrics in one place. But remember metrics alone aren't good enough unless you can make them actionable.
We spend most of our time thinking about how to create the perfect user experience to allow engineering managers to go from data -> insight -> action with the least amount of effort.
