The pursuit of predictably in delivering projects made tracking agile software development metrics a standard practice for many executives and dev leaders. Undoubtedly, the right software metrics can give you insight into your team’s day-to-day performance, progress towards the final deliverables, and potential bottlenecks.
Yet, metrics are only measures. When set incorrectly, they can drive more confusion, than clarity. To help you avoid such scenarios, we have prepared this short guide, explaining how to approach software development metric selection. Let’s start with the basics.
What are Software Development Metrics?
Atlassian defines IT metrics as quantifiable measurements IT leaders can use to:
- Understand the value of produced technology
- Gauge the development team performance levels
- Demonstrate the value of produced work to non-tech leaders.
In other words, the right line up of IT performance metrics can help you:
- Bridge the communications gaps between dev leaders and business executives.
- Align your distributed teams with your organizational objectives.
- Understand whether the development process is stirred in the right direction.
- Predict future performance outcomes with higher confidence.
All of the above ultimately helps you minimize the risks in software development.
To Track or Not to Track?
On the surface level, the idea of pinning every process to an IT metric may seem sound.
However, becoming metrics-obsessed or using a “one-size-fits-all” approach can backfire.
Here’s why: every project pursues certain business goals and thus has unique complexities. That’s why you should carefully weigh in on your choice of metrics and avoid copying them from another project. Instead, you should align your metrics to your current project goals. The goal of the metrics is to help you gain instant answers to the core business questions e.g. how well is your team progressing? What’s blocking them from doing even better?
On the other hand, going too narrow with your choice of metrics isn’t an option either. Individual IT metrics have boundaries. A single metric cannot fully communicate how well your team is progressing and whether the final product will meet all your expectations.
That’s why you should always opt for a combination of metrics. Based on the top CIOs’ responses, the ideal balance is 56% of metrics related to business outcomes, such as revenue growth, business margins, influencing business strategy, and 44% related to IT delivery.
8 Baseline IT Performance Metrics To Monitor
Every project is different. But most SDLC practices stay the same. To get a better sense of how your team progresses at different cycle stages, you should track the following set of metrics:
Sprint Burndown
A sprint burndown metric (often presented as a chart) showcases the completion of work during the sprint against the team forecasts. Ideally, all the forecasted items (tickets, user stories, tasks, etc.) should be completed by the end of the sprint. At Edvantis, we use Atlassian Jira to visualize sprint burndown rates during remote Sprint reviews.
By tracking sprint burndown, you can estimate whether:
- There’s enough work scheduled for each sprint (especially if the team finishes each task ahead of time).
- The team commits to an excessive amount of parallel tasks that don’t get finished on time. This results in missed deadlines.
- The total scope of work hasn’t been properly decomposed into lower-level tasks. You can notice this trend when instead of a steep reduction of remaining tasks, you see a dramatic drop.
Team Velocity
Mainly used for forecasting, team velocity measures the average amount of work (either in story points or in hours) a team completes during a sprint. By tracking velocity, you can estimate how quickly a team can work through the backlog.
Measuring team velocity helps:
- Set realistic sprint forecasts and proper delivery expectations.
- Understand if earlier improvements were efficient. If not, investigate the reason behind that.
- Identify if a team has blockers (i.e., falling velocity often indicates technical debt or hidden complexities).
Important caveat: do not set the same velocity metrics for two different teams since each team works at its own pace on different sets of tasks. Comparing inter-team velocity will lead to biased results.
Cycle Time
Cycle time is the total time spent on a software task from the very beginning and until completion. By knowing your team’s average speed at different stages of the development process, you can identify potential blockers early on and resolve those.
Measuring cycle time also helps:
- Set more accurate timelines
- Identify progress breakdowns
You can track and visualize your cycle time using an issue management system like Pivotal Tracker or Jira.
Throughput
Throughput measures the total number of work units (usually tickets, but can also include story points and cards) completed by the team over an agreed period. This metric indicates your team capacity to deliver results over a fixed period of time.
By measuring throughput, you can also:
- Check whether the team is blocked (throughput drop)
- Plan team capacity (compare the average throughput against the current workload)
Note: Throughput has its limitations as it provides a cursory view over your team’s work dynamics. If your team could crack 7 simple user-stories last month, and only 2 complex ones this month, it does not translate to a performance drop.
Work in Progress (WIP)
WIP refers to any work that your team has committed to but not finished yet. This metric gives you an insight on how much work is ongoing at the moment (the number of unfinished cards or work items).
By tracking WIP, you can:
- Improve the overall flow of value through your system
- Understand your team capacity and identify possible bottlenecks
You can measure WIP by using a cumulative flow diagram or simply by counting the relevant cards on your Kanban board. Tracking WIP weekly is an excellent way to understand the amount of work you have under development.
Defect Density
Defect density indicates the number of defects (bugs) found per 1,000 lines of code. You can calculate it using the following formula:
Defect Density = Total Number of Defects / Total Number of Modules.
The defect density can help you:
- Measure the testing effectiveness
- Identify a module that needs changes (high defect density number)
- Point towards high-risk components
The underlying idea here is simple: the higher the defect density, the lower the code quality. Yet, this metric can be somewhat misleading since it doesn’t consider the complexity of the code. Another pitfall is that it can often be calculated wrong by indicating only the number of defects caught in one day. Defect density has a cumulative nature, and so its total number grows as the product is being developed unless you take actions to fix those defects.
Lead Time
Lead time is an agile metric measuring the amount of time between the new task’s appearance until its completion. To calculate it, use a simple formula:
Start time + Cycle time = Lead time.
The lead time metric is useful to:
- Evaluate changes and forecast future work
- Estimate how long can it takes for the team to get through your product backlog
- Determine the impact of any changes you make
- Assess how well your team is performing
Lead time can help you make more precise predictions on the percentage of work done during a specific period.
Code Coverage
Code coverage is used to ensure that testing standards, established at the outset of the project, are maintained throughout the development and release cycles. It’s a handy metric that can give you insight into the quality of your test suite.
Usually, code coverage includes function, statement, branches, condition, and line coverage metrics. So this metric can help you understand if your automated test coverage is sufficient.
However, code coverage doesn’t reflect the whole test/code quality, hence should be used together with other metrics (e.g. defect density) to show the complete picture.
The tool choice for monitoring code coverage will depend on the programming language you use. Some of the popular tools are Atlassian Clover (multi-language), Cobertura for Java, Istanbul for Javascript, SimpleCov for Ruby, and Coverage.py for Python.
To Conclude
When your end-goal is higher and more stable team performance, the right metrics can help you proactively monitor your project progress without resorting to micromanagement. So that you could identify and respond to potential blockers, resolve rising issues at the onset, and continuously ramp-up your team’s delivery pace.
As part of our managed team model, Edvantis consults every customer on the optimal set of IT performance metrics and supporting managerial practices to back up the delivery process. Contact us to learn more!
