Key Metrics for Agile Teams: From Lead Time to Security Indicators

Steven A. Lowe, a Product Technology Manager at Google, introduces a set of nine objective metrics that software development teams should adopt to improve performance and business value.

Agile Process Metrics

Lead time – the total time from idea to delivery, indicating how quickly a team can respond to customers.

Cycle time – the time required to make a change and push it to production, often measured in minutes for continuous‑delivery teams.

Team velocity – the amount of work a team completes in a sprint, useful for planning but not a direct success indicator.

Defect open/close rate – the number of reported and resolved production issues over a period, where trends matter more than raw counts.

When any metric deviates from expectations, teams should investigate the story behind the numbers rather than guessing causes.

Production Analysis

Mean Time Between Failures (MTBF)

Mean Time To Recover/Repair (MTTR)

Application crash rate – crashes divided by usage, related to MTBF and MTTR.

These metrics assess software reliability in production; lower values are better, but they do not reveal which features or users are affected.

Security Metrics

Endpoint incidents – number of devices infected by malware during a period.

Security MTTR – time between discovering a vulnerability and deploying a fix; decreasing values show improved security response.

Both metrics indicate progress toward a more secure product.

Source‑Code Metrics

Automated scanners can generate many objective metrics (e.g., code style violations, anti‑pattern detections). While useful for trend analysis, teams should avoid obsessing over raw numbers and focus on actionable insights.

Using Metrics for Success

Metrics should answer specific business questions, validate hypotheses, and guide decisions. Successful teams define clear value hypotheses for each feature, measure the relevant outcomes (e.g., checkout speed vs. cart abandonment), and adjust or discard metrics when they no longer serve the goal.

Six Heuristics for Effective Metric Use

Metrics alone don’t tell the whole story; the team does.

Comparing “snowflakes” (tiny differences) wastes effort.

You can measure almost anything, but you can’t focus on everything.

Only business‑success metrics drive software improvement.

Every feature should have a measurable value or be omitted.

Measure only what matters right now.

By concentrating on the right metrics and continuously refining hypotheses, teams can align engineering work with business success.