6 Software Metrics Your Organization Should Track

The Art of Choosing Software Metrics That Matter

It's hardly a science. Try drafting a framework that fits every business. The fact that there exist so many metrics is because every company is unique. At some point, IT leadership has to deliberately invest greater attention in software metrics. Especially those that give them the notion of control over the business now and into the future. 

For balance, let's establish (loosely) the definition of a metric as a measurable state or outcome. It should then quickly become evident that some metrics carry more weight than others. 

Does the number of employees who show up for work matter enough to keep tabs on? Not when we could be measuring how much work needs to be done. Subtle relationships between these two measurables can influence our focus. More importantly, they furnish us with decision-making tools that affect the business in both short and long time frames. 

If there's a low turnout but the work done stays the same regardless, then perhaps you're overstaffed. You know what to do then. Right? 

It's easy for your vision to get blurry when looking at activity from all the applications in your charge in a single view. Especially when you're managing your value creation process with tools that spew out raw data. At the very least, it's hard to know how much work is being done on the flow. 

You may as well be using a spreadsheet with all columns filled to show states for all active (and past) work items. Even then, we've curated a list of software metrics crucial to making decisions for the good of your business. 

1. Work in progress (work items)

2. Lead time

3. Cycle time

4. Work items throughput

5. Work items age

6. Flow efficiency

Let's look at each metric in more detail. 

Work in Progress

The first software metric on our list is an integer value of the number of tasks open. These tasks will have passed the planning stage of an agile workflow. As long as an actor is assigned to the task, it should be counted as a work in progress (WIP). 

Limiting WIPs helps maintain peak performance among team members. The risk here is having too many tasks begging for attention. A situation that could lead to low quality at best, and paralysis of workflow. Every business should have this metric in their sights and be cognizant of the average time it takes for fresh teams to ask for more. This brings us to the next software metric worth monitoring. 

Lead Time

The best way to think about lead time is by considering how long it takes from when a task appears on the planned activities list (backlog) until it gets signed off (completed)—i.e., start to end. Include any time before an actor (yet to be assigned) begins focused work on the task. 

Timeline showing a task from start to finish on an agile board

The number of tasks in the backlog section of an agile table grows as long as there's no one acting on any tasks. Task count also raises when actors are too few to sustain new tasks. Both scenarios are directly responsible for long lead times. 

A key objective for IT leadership is to predict lead time. Where possible, you should also be on the lookout for the opportunity to optimize action time within known lead times—also known as cycle time. 

Cycle Time

Whenever a task lands in the charge of an actor, we can start counting the duration it takes for them to complete it. This time is labeled as cycle time. In reality, there may arise unintended stops even when work on a task has begun. It's the chore of product managers to note and account for any idle time and deduct it from the cycle time for a homogenous statement of project time lapse. 

Work Items Age

Every work item's lifetime should be recorded from the moment it appears on a workflow chart. Officially known as work item age, the older a task gets before completion, the more attention it attracts. It's worth reviewing the oldest work items to analyze why they're not moving through your boards. 

It's easy to get lost in a census fixated on numbers when recording work items age. The key, instead, is to track trends. This way, you can decode deeper events and reasons why (if that's the case) tasks take so long to complete. 

Work Items Throughput

Throughput is determined by the number of work items completed for any stipulated period of time (say, weekly).  When plotted on a graph against time, you should be able to notice slopes that, at first view, suggest productivity. However, throughput neglects the severity (degree of difficulty) of any work items that may have passed through your measuring point. Even still, it serves to help you determine trends in your team's rate of work. You're best using work item throughputs in conjunction with other agile metrics for more informed decision-making. 

Flow Efficiency

Flow efficiency is a different kind of software metric in that it is calculated from other metrics and not just observable activities. In a nutshell, it's a calculation of how difficult it is for your tasks to get the attention they need. Keep in mind how even cycle time is not entirely comprised of productive moments. Gaps therein can arise while actors wait for dependencies. They could also be on halt due to system downtime. All of which should be accounted for and polished out of cycle time as you perfect your value stream processes. 

Getting Teams on Board With Software Metrics Tracking

Personally knowing what to measure is just the first step for you in moving your organization toward making informed decisions en masse. Knowing the attention span of most leaders, your best shot at getting their minds wrapped around these six software metrics is if they're shown on a single dashboard. See Plutora's Value Stream Flow Metrics Dashboard screenshot below as an example. 

When you take a step back, all six make up the core of a company's value stream flow metrics. Figuring out what everyone is working on, how, and when they'll be done becomes child's play. So will pinpointing impediments within your workflows. Comparing the readings over time, you'll benefit from a more productive value stream process fortified from the ground up.