11 Metrics to Help Keep a Finger on the Pulse of Software Delivery

An old adage states, “You can’t improve what you can’t measure”, and nothing could be truer when it comes to boosting a team’s productivity

Companies are on the hunt for the secret to productivity — the art of increasing the amount of useful outputs from quantifiable inputs. The world of software development is one of which where countless leaders seeking this Holy Grail. Unfortunately, they either fall short trying or lay one hand upon it to realise it doesn’t resemble what they’d originally set out to find.

I too am still looking to unlock the secrets of productivity but what I have learnt so far is that there is no silver bullet or shortcuts to achieve it.

I’ve come to believe that enhancing productivity is the side-effect of incrementally refining the building blocks of several interrelated processes and subsystems. By focusing on aspects such as predictability, accountability, employee engagement & wellbeing, transparency, and quality; the much sought after goal of productivity becomes attainable.

But how do you know when you are on the tipping point of making an impact upon productivity? By utilising select metrics that are both curated and owned by software delivery teams, insight into progress can be tracked. A spotlight is cast across the metaphorical playing field, the causality of each variance in the process can be assessed and the impact upon productivity explicable.

By focusing on aspects such as predictability, accountability, employee engagement & wellbeing, transparency, and quality; the much sought after goal of productivity becomes attainable.

This article looks to introduce you to these metrics; some familiar and possibly some not so well-known.

For the sakes of this article, I refer to Jira as my weapon of choice to track the metrics but I’ve found Azure DevOps works perfectly well also.

Sprint Burndown

What is the metric?

Tracks completion of work throughout a Sprint
Measured by plotting the remaining effort left each day

How do we measure it?

Captured by setting each subtask with an estimate
As each subtask is completed the remaining effort is reduced
Burndown is automatically plotted as this happens

Why do we measure it?

Helps teams understand if they are under or over forecasting
Steep drops in the burn highlights when work hasn’t been broken down into granular pieces

Epic & Feature Burndown

What is the metric?

Track progress of development over a larger body of work compared to Sprint burndown
Shows the amount of effort left to complete per epic or feature

How do we measure it?

Plotted by collating issues related to a particular feature in an epic
As each issue is completed within an epic this is shown as work completed in the epic burn
As more work is added to an epic this is also highlighted in the epic burn chart

Why do we measure it?

Sprint burndown charts alone do not give enough visibility of on-time delivery of project
Highlights scope creep
Can indicate when teams aren’t shipping incremental releases

Velocity

What is the metric?

Average amount of work completed each Sprint
Measured in story points

How do we measure it?

Captured in Jira from teams estimations of issues in Backlog Refinement
As each issue is added to a Sprint Jira plots the committed work
As issues are completed during the Sprint Jira plots the work completed against work committed

Why do we measure it?

Useful for forecasting how much work a team can complete
Issues with erratic variance can highlight issues with team estimations or prediction of commitment
Consistent velocity could demonstrate a team is running well or can increase their commitment

Actual Items Completed vs. Committed Items

What is the metric?

Displayed on the same chart as velocity
Used to understand the number of stories the team managed to complete against their predicted target

How do we measure it?

Captured in the same way as velocity

Why do we measure it?

Helps teams review if they are overestimating
Can highlight where teams who consistently achieve their predicted target may not be committing enough
Can help a team understand if their estimations are accurate

Technical Debt Management

What is the metric?

Known problems, issues or bugs delivered during Sprint
Measured by number of bugs but this can be expanded

How do we measure it?

Using bugs issue types in Jira we can report on the number of bugs added during a Sprint

Why do we measure it?

Helps the team review development process to ensure that fewer bugs are deployed into the quality assurance environment
Can highlight areas where existing unit tests are not covering all paths

Team Enthusiasm & Satisfaction

What is the metric?

Major component in a successful Scrum team
Indicator of the morale and happiness of the team at the end of each Sprint

How do we measure it?

Satisfaction survey taken in each Retrospective / end of Sprint

Why do we measure it?

Help the team reflect on their adoption of Scrum
Surfaces possible issues with process if team motivation is low

Retrospective Process Improvement

What is the metric?

Review of the actions committed and completed that were taken from the last Retrospective

How do we measure it?

Any actions captured in a Retrospective should either have a deadline set or be committed to a future Sprint
These can then be measured by their delivery time

Why do we measure it?

Demonstrates the teams ability to revise its development processes to make the next Sprint more effective and enjoyable
Highlights where issues have been found but corrective action has not been taken

Team’s Adherence to Existing Methodology

What is the metric?

Ensures that the Scrum team follows the rules and standards set for your Agile processes

How do we measure it?

Measured as a count of infractions to the standards during the Sprint Retrospective

Why do we measure it?

It is important that all teams adhere to standards and governance set — deviations to the process can be made as long as it’s a conscious decision agreed upon by the team
Can prevent teams moving into low satisfaction
Highlights potential failure points early on so corrective action can be taken

Value Delivered per Iteration

What is the metric?

Measures the value a team delivers at the end of each Sprint

How do we measure it?

Using a value field of the Issue in Jira
A report can be pulled from Jira of a count of value for each Sprint

Why do we measure it?

Downward trends can highlight when to stop working on a particular product
Early indicator to show that team could be moved onto a higher value project

Time to Market

What is the metric?

Length of time it takes for a project to provide value to the customer
Can be measured by revenue or delivery of feature to customer

How do we measure it?

Can be measured by setting milestones for epics or features to be delivered in Jira

Why do we measure it?

As an Agile team it is important to show the iterative benefit delivered to customers
Late ROI can indicate estimation issues or team not iteratively deploying features

Capital Redeployment

What is the metric?

Compares the cost of future development against the potential value of that work

How do we measure it?

The value of the remaining requirements is compared to the actual and opportunity costs combined

Why do we measure it?

Can indicate when to redeploy a development team onto a new project if the costs outweigh the potential value gain

With these metrics being tracked, you and your software delivery team should be on the path to unearthing productivity gains.

One final word of advice to encourage your team in the adoption of these metrics — ensure that these figures remain under the ownership of your team and not that of senior management. They are there to help the team to observe and analyse their own performance. It’s far too easy for these metrics to be misconstrued outside of the context of your team leading to a counter-productive hit to the team’s delivery.

If there’s any useful metrics that I’ve not covered, I’d love to hear about them in the discussion thread below.