Introduction
Measuring an Agile team is easy. Measuring something useful about an Agile team is hard. The wrong metrics drive the wrong behavior — teams optimize for what is counted (velocity, hours, story points) at the expense of what actually matters (customer outcomes, learning rate, system health). Goodhart's Law shows up the moment a measure becomes a target.
The metrics in this hub are organized around what they reveal rather than what they count. Some point at product strategy (OKRs, North Star), some at customer behavior (pirate metrics, NPS, journey health), some at the health of the team itself (happiness, maturity radars). Used carefully, they help teams steer. Used carelessly, they become the next thing to game.
Topics
Team Happiness Metrics
Lightweight pulse signals — mood, energy, confidence — tracked over time so trends become visible before crises do.
Read →NPS for Agile Teams
Adapting Net Promoter Score for product feedback loops, and the limits of relying on it as a single number.
Read →Customer Journey Mapping
Measuring health across each step of the customer journey rather than at aggregated funnel boundaries.
Read →AARRR Pirate Metrics
Acquisition, Activation, Retention, Referral, Revenue — Dave McClure's five product-funnel metrics for early-stage products.
Read →North Star Metrics
The single product metric that best represents the value your team delivers, used to align decisions across the org.
Read →Lean Analytics Stages
Croll and Yoskovitz's framework for the one metric that matters depending on product stage — empathy, stickiness, virality, revenue, scale.
Read →OKRs
Objectives and Key Results as a goal-setting framework — ambitious outcomes paired with measurable signals of progress.
Read →KPIs
Key Performance Indicators for ongoing operational health, distinguished from OKRs by their stability over time.
Read →Balanced Scorecard for Agile
Kaplan and Norton's four-quadrant approach adapted for Agile contexts: financial, customer, internal process, learning & growth.
Read →AgilityHealth Radars
Multi-dimensional team and program health assessments that visualize maturity across foundations, leadership, technical, and outcomes.
Read →Using Metrics Honestly
The first rule is to know what each measure is for. Outcome metrics (revenue, retention, NPS) describe the world the team is trying to change. Output metrics (velocity, deploys per week) describe what the team produces. Health metrics (cycle time, happiness, defect rate) describe the team itself. Confusing the three is how teams end up celebrating velocity while shipping the wrong things.
The second rule is to measure with a hypothesis. "We think shorter cycle time will improve customer satisfaction" is a hypothesis worth testing. "We measure cycle time" is a number waiting to be optimized in isolation. The metric earns its place by being tied to a decision — what would the team do differently depending on what the number says?
Back to Hubs