Metrics and Learning

Metrics and Learning is not about tracking velocity or producing dashboards to appease managers. It’s about creating the conditions for continuous improvement by making performance transparent, exposing constraints, and enabling teams and leaders to respond with evidence rather than assumption.

This approach builds a culture of empiricism, where progress is inspected regularly, and data informs decisions. Metrics become a feedback loop, not a control mechanism. They allow teams to observe how value flows, understand where it’s blocked, and adapt their systems of work accordingly. If you’re not measuring flow, quality, and outcomes, you’re not managing; you’re guessing.

Metrics are not just about operational tracking, they are a leadership tool for adaptation.

To make this work across your company, we recommend metrics in two distinct but complementary domains: the Product/Project/Organisation- level and the Team- level.

Product / Project / Organisation Metrics

These metrics help us understand the overall health of delivery, customer experience, and organisational capability. They are most useful for Product Owners, stakeholders, and leaders who are accountable for strategic outcomes.

• Customer Satisfaction Gauges sentiment and product-market fit. This is not a vanity metric. It’s a leading indicator of retention and advocacy.

• Employee Satisfaction A reflection of team energy and engagement. Low engagement correlates with low throughput and high turnover. If your people aren’t engaged, your product won’t be either.

• Defect Trend A measurement of quality debt. A rising trend signals instability and rework. Quality is a strategic asset, not a developer problem.

• Mean Time to Repair (MTTR) Reveals how quickly your system can respond to issues. This is an indicator of your DevOps maturity and your ability to protect customer trust.

• Release Stabilisation Duration The time between “dev done” and “customer live.” Long stabilisation windows indicate brittle systems and poor engineering practices. This metric tells you how much of your time is spent undoing versus delivering.

• Deployment / Release Frequency Frequency reflects feedback speed. If you can’t release frequently, you can’t learn quickly. If you’re not releasing frequently, you’re not Agile, no matter what your board says.

Team Metrics

At the team level, metrics should reflect how effectively value flows through the system. These are diagnostic tools for self-management and improvement, not tools for judgement or control. They inform the team’s own decisions.

• Work in Progress (WIP) High WIP kills flow. It reveals where context switching and overcommitment are damaging delivery. Monitor WIP to guide WIP-limiting policies and optimise flow.

• Cycle Time How long does it take to turn an idea into a done increment? Trends over time are more important than single snapshots. Stability is more important than speed.

• Work Item Age Every in-progress item has a clock ticking. A rising average suggests bottlenecks or neglected work. Use this to spot hidden queues.

• Throughput Count of items completed per time unit. Don’t over-index on it. It’s only useful when paired with WIP and cycle time to observe trends.

We explicitly do not- track velocity, story points, remaining work, or original estimate. These are internal planning tools, not outcome metrics. They promote illusion over insight and encourage teams to optimise for the wrong things.

Closing the Loop

Metrics are only useful when they’re tied to learning and action. That means:

• Teams inspect them regularly (e.g. during Sprint Reviews and Retrospectives).
• Product Owners use them to inform forecasting and prioritisation.
• Leaders use them to support, not control, enabling system-level improvement rather than micromanagement.

By embedding metrics in how we work, we move from anecdote to evidence, from hope to hypothesis, and from activity to outcomes.

We don’t measure to report. We measure to learn. We don’t track metrics. We inspect systems.