Software Project Metrics: What to Measure and Why

Software project metrics are useful only when they answer a decision: whether delivery is getting faster, whether the product is getting more stable, whether the budget is buying the outcome it was meant to buy. The metrics that meet this standard fall into four families: flow (lead time, cycle time, throughput), delivery performance (the DORA metrics), product quality (ISO/IEC 25010 characteristics) and team health (the SPACE dimensions). This article sets out what each family measures, how the figures are read, and where they mislead.

TL;DR

• No single figure describes a software project. A small set of metrics from different families, read together, gives a balanced view.
• Lead time is the wait as the customer experiences it. Cycle time is the active working period as the team experiences it. The gap between them is queueing.
• The DORA research programme defines five delivery metrics and shows that speed and stability reinforce each other rather than compete.
• Activity counts such as commits or story points become distorted once they are used as targets. They should be paired with outcome and perception measures.
• Metrics should be applied per application or service, with a stated decision attached to every figure.

Table of Contents

• Why metrics fail before they are collected
• Flow metrics: lead time, cycle time and throughput
• Delivery performance: the DORA metrics
• Product quality: what ISO/IEC 25010 adds
• Team health: the SPACE framework
• Project outcome metrics: connecting delivery to the business
• Choosing a starting set
• Common distortions
• Our perspective
• Getting help with measurement and delivery
• FAQ
• Sources

Why metrics fail before they are collected

Most measurement programmes fail at the design stage, not at the tooling stage. A dashboard is assembled from whatever the issue tracker exports, the figures are reviewed monthly, and no one can state which decision any of them would change. The result is reporting that describes activity without informing management.

A sound selection starts from the questions a sponsor actually asks. Is the project on course to deliver what was agreed, and when? Is the quality of the product acceptable to the people who use it? Is the cost of change rising, which would signal accumulating technical debt? Is the team sustainable at its present pace? Each question maps to a family of metrics, and each family has a typical failure mode that the following sections describe.

Two principles recur throughout. First, a metric used as a target ceases to measure what it measured before: a team rewarded for commit counts will produce commits. Second, context determines meaning, so a figure from one system cannot be compared with a figure from another without accounting for stack, architecture and deployment constraints.

Flow metrics: lead time, cycle time and throughput

Flow metrics describe how work moves through a delivery system. They are the most practical starting point because they can be derived from the timestamps already held in a ticketing tool, and because they expose delay rather than effort.

Lead time and cycle time compared

The two terms are frequently used interchangeably, which produces confused reporting. Screenful’s guide to timing metrics draws the distinction: lead time runs from the moment a customer places a request to the moment the finished item is delivered, whereas cycle time runs from the moment the team begins active work on the item until it is completed. Kanban Global frames the same distinction by perspective: lead time is the customer’s view, cycle time is the team’s view, and the difference between them is the queue before work starts.

The practical consequence is that a team can show an excellent cycle time while the business experiences slow delivery. If requests wait six weeks in a backlog and are then completed in three days, the sponsor perceives a six-week service. Reporting both figures prevents the team from appearing efficient while the organisation is slow.

Reading the gap between the two

According to the same Screenful analysis, the gap between lead time and cycle time is primarily the time items spend waiting in queues, and limiting work in progress is a standard way of narrowing it. This is consistent with queueing intuition: when many items are started at once, each one waits longer for attention, so overall completion slows even though everyone is busy.

When the gap is large, the remedy is rarely to ask engineers to work faster. It usually lies in refining how work is accepted, limiting concurrent items, shortening approval chains and breaking items into smaller increments. A cycle time distribution is more informative than an average. Reporting the median together with a high percentile, for example the figure within which 85 per cent of items complete, tells a sponsor what a realistic commitment looks like and how unpredictable the tail is.

Throughput and work in progress

Throughput counts completed items per period. It is meaningful only if items are of broadly similar size, which is why teams that slice work finely tend to forecast more reliably than teams that estimate large items in points. Throughput, work in progress and cycle time are linked, so a change in one is usually visible in the others. A rising count of items in progress with flat throughput almost always precedes a deterioration in cycle time.

Delivery performance: the DORA metrics

Flow metrics describe the process in general. The DORA programme, which has studied software delivery performance for several years, focuses on the part of the process that ends in production. According to DORA’s guide, five metrics together give an effective way of measuring the outcomes of the delivery process, covering both throughput and stability.

The five measures

The 2024 Accelerate State of DevOps report describes them as follows, with the reported figures for elite performers where it gives them.

Note that DORA’s change lead time is narrower than the lead time discussed above. It begins at the code commit, not at the customer’s request. A project sponsor interested in responsiveness should therefore track both: the request-to-delivery lead time for planning, and the commit-to-production figure for engineering health.

Speed and stability are not opposites

A persistent belief in management is that faster release means more breakage. DORA’s researchers dispute this. As Nathen Harvey explains in DORA’s guide, high-performing teams achieve speed and stability together, so improvements in throughput and in stability should be read as reinforcing signals. The mechanism is straightforward: small, frequent changes are easier to test, easier to review and easier to reverse than large batches released rarely.

Apply them to one service at a time

The same guidance warns against blending these metrics across several teams or a whole organisation, because delivery context such as technology stack and deployment complexity varies significantly between applications. A monolith with a quarterly regulatory release window and a stateless API deployed daily will never share a meaningful average. The sensible unit of measurement is one application or service, tracked against its own history. League tables between teams invite the very gaming that undermines the data.

Product quality: what ISO/IEC 25010 adds

Delivery metrics say nothing about whether the product is good. For that, the usual reference is ISO/IEC 25010, which defines eight quality characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability and portability. A 2025 study of software quality attributes in requirements notes that ISO/IEC 25023 supplies quantitative measures for each characteristic, classified as internal or external.

The same study argues that not every characteristic carries equal weight on every project, and that functional suitability and compatibility are foundational for most businesses. This is the right way to use the standard: as a checklist from which a project selects the few characteristics that matter most and then agrees measurable thresholds for them at the outset. The table shows how such a selection might translate into project metrics.

The examples in the right-hand columns are illustrative choices, not values prescribed by the standard. Their purpose is to show that each quality attribute becomes manageable only once a number and a threshold are attached to it before development begins.

Team health: the SPACE framework

Flow and quality figures can both look healthy while the team that produces them is exhausted. The SPACE framework, set out in an ACM Queue article by Forsgren and colleagues, holds that developer productivity cannot be measured by a single metric or dimension. It names five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.

The authors recommend combining metrics from several dimensions, and a commonly cited guideline is to capture at least three, ideally from different dimensions, so that they pull in different directions. Pairing an activity measure such as pull requests merged with a perception measure such as a short periodic team survey is the standard illustration. If activity rises while satisfaction falls, the improvement is probably borrowed from the future.

Measuring the effect of AI assistants

Tools that generate code complicate the picture. A recent study of generative AI and developer productivity describes how apparent gains, such as faster task completion, can be offset by hidden costs including heavier code review, the cognitive load of verifying generated output, and collaboration patterns that do not change. These costs remain invisible when only output figures are tracked. Organisations adopting such tools should therefore watch review time, change failure rate and team perception alongside raw speed.

Project outcome metrics: connecting delivery to the business

Everything above concerns the build. A project sponsor ultimately cares about whether the delivered software achieves a business purpose, and that requires a separate layer of outcome metrics defined during discovery: conversion rate for a customer-facing platform, processing time per case for an internal workflow, adoption among the intended users, cost per transaction after a migration. For web products, a primer on measuring website success through KPIs and tools covers the audience-side figures that sit beside engineering metrics.

Outcome metrics change the conversation about scope. If a feature cannot be linked to any outcome measure, it is a candidate for deferral. If an outcome measure fails to move after a release, the project has learned something that no delivery metric could have shown, namely that the hypothesis was wrong, not that the execution was slow.

Choosing a starting set

A workable measurement set for a project of moderate size is deliberately small. It combines one or two figures from each family, with an owner and a review cadence for each.

The baseline should be recorded before any improvement initiative begins, since a figure without history cannot show progress. Definitions should be written down: what counts as a deployment, what counts as a failure, when the lead time clock starts. Disagreement over definitions is the most common reason the same metric yields different numbers in different reports.

Common distortions

Several patterns recur in practice and are worth anticipating.

Velocity, measured in story points, is a planning aid internal to one team. Compared across teams, or tied to performance reviews, it inflates. Lines of code and commit counts reward volume and penalise refactoring, which often removes code. Utilisation targets near full capacity lengthen queues, because there is no slack to absorb variation. Averages conceal long tails, so a single item that took ten weeks can be invisible in a mean that looks healthy. Finally, metrics reported without commentary invite misreading: each figure should reach the sponsor with a sentence stating what changed and what is proposed.

Our perspective

We build and maintain software for organisations across EMEA and North America, and the pattern we see most often is not a shortage of metrics but a shortage of agreement about which ones matter. Reporting layers between the people who write the software and the people who fund it tend to flatten the numbers into status colours. Our delivery model removes the account-manager layer, so the engineers who make the architectural decisions are the same people who read the lead time chart with the client, and a rising failure rate leads to a technical conversation instead of a rewritten summary.

In practice we recommend that a client agree a short list at the start: a handful of flow and delivery measures, the quality characteristics that matter for that product, and one or two business outcomes. We limit the number of simultaneous projects we take on, partly so that this reporting is done properly and not as an afterthought. When we advise on architecture, code audits or technical debt, the recommendations are delivered in writing, with the measures against which their effect can later be judged.

Our firm view is that a metric the engineering team cannot influence, or a figure no decision depends on, should leave the dashboard.

— Pepe F.

Getting help with measurement and delivery

For organisations that want an independent technical view of their delivery before committing to a programme of change, we offer an initial assessment from €3,500 (one-off), and ongoing CTO-level support through CTO Advisory from €1,800 per month, Fractional CTO from €4,000 per month and CTO Partner from €7,500 per month. The plans and what each includes are set out on our CTO advisory page. Our wider range of work, from custom development to code audits and AI integration, is described on the services page.

FAQ

What is the difference between lead time and cycle time?

Lead time covers the whole wait from a customer’s request to delivery. Cycle time covers only the period from the start of active work to completion. The difference between the two is mostly time spent queueing, which is why Kanban Global presents lead time as the customer’s view and cycle time as the team’s view.

How many metrics should a software project track?

Few enough that each has an owner and a decision attached. The SPACE authors advise capturing at least three metrics, ideally from different dimensions, to avoid optimising one at the expense of others. For most projects, between six and ten figures across flow, delivery, quality, team health and outcomes is workable.

Can DORA metrics be used to compare teams?

They are poorly suited to it. DORA’s guidance states that the metrics are best applied to one application or service at a time, because context such as stack and deployment complexity differs widely. Each team should be compared against its own trend.

Are velocity and story points reliable project metrics?

They are useful for a single team planning its own next iteration, and unreliable beyond that. Story points are relative estimates with no common unit between teams, and they tend to inflate when treated as a target. Throughput and cycle time based on completed items are usually a sturdier basis for forecasting.

Sources

• DORA: software delivery performance metrics
• 2024 Accelerate State of DevOps report
• Screenful: Lead time vs cycle time
• Kanban Global: Lead time vs cycle time in Kanban
• Software Quality Attributes in Requirements
• The SPACE of Developer Productivity, ACM Queue
• The Fast and Spurious: Developer Productivity with GenAI

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.