From Metric Overload to Focused Insights: A Software Engineering Manager's Journey

Over the course of time as an engineering leader, I've seen my fair share of trends come and go. But perhaps none has been as persistent – and at times, overwhelming – as the push for metrics. I remember a time when our dashboards were cluttered with every conceivable data point. We tracked it all: lines of code, number of commits, story points, bugs per feature, and the list went on. It was a data deluge and frankly, it was drowning both our teams and leadership.

Don't get me wrong – data is invaluable. But too much of a good thing can be, well, too much. 

At Allstacks - it is a question we continually ask when it comes to metrics. What is important to measure and improve today and what does great ultimately look like.  We continually take a step back with our customers to evaluate and ask ourselves: What should our metrics journey look like, where do we start and how do we evolve? After much deliberation and some trial and error, we narrowed it down to three key metrics to get started:

  1. Cycle Time -  Cycle time measures the duration from when work begins on a task to its completion. This metric is vital for several reasons:
    • It highlights bottlenecks in the entire development lifecycle
    • Shorter cycle times often correlate with higher quality and team satisfaction
    • Tracking cycle time trends helps in estimating future work more accurately

2. Code Quality - Code quality metrics provide insights into the health of your codebase. Key aspects to monitor include:

  • Defects found within a sprint and kicked back to “in progress”
  • Defects escaped to production
  • Time to repair defects escaped

3. Team Velocity - Consistent velocity is often more valuable than high velocity, as it enhances predictability. Importantly, velocity is negatively impacted when code quality is subpar. Poor quality code leads to:
  • Increased bug fixes and rework, reducing time for new features
  • Slower development as engineers navigate complex, poorly structured code
  • More time spent on maintenance, decreasing overall productivity
  • Unpredictable delays due to unexpected issues, making sprint planning difficult

One potential additional consideration - Use the concept of “Net Velocity” to measure overall performance inclusive of quality and needed repair time.  Net Velocity’s formula is ((Total Velocity - ( Time to repair escaped bugs + Time to repair bugs found intra sprint)).  This is useful when attempting to understand the negative cost of bugs introduced and the associated repair time.

The Importance of Predictability - The real magic happens when you experience the interplay of these metrics. High-quality code leads to better velocity. Improved cycle time causes consistent velocity. It all feeds into the holy grail of software development: predictability.

  • Predictability might sound boring, but let me tell you – it's a game-changer. When we can reliably tell our stakeholders when features will be delivered, trust will skyrocket. Resource allocations and time management will be smoother and ultimately quarterly roadmapping sessions are transformed from contentious guessing games to data-driven discussions.
  • Now, don't get me wrong – don’t throw out all other metrics, still keep an eye on other data points. But these three – cycle time, code quality, and team velocity – form the core of our recommended metrics strategy. They're the ones to review with discipline, the ones that drive our continuous improvement efforts.

So, if you find yourself drowning in dashboards and metrics, take a breath. Step back. Ask yourself what really drives value in your development process. You might find the path to better software delivery isn't through more data, but through more focused, actionable insights that grow and mature over time.

Contact us today to: Get Predictable!

Can’t Get Enough Allstacks Content?

Sign up for our newsletter to get all the latest Allstacks articles, news, and insights delivered straight to your inbox.