Agile metrics: What to track and why they matter (2026)

Most agile metrics guides hand you a list of charts, tell you what they measure, and leave you there. That is the easy part. The hard part is figuring out which numbers are worth your development team's attention, which ones quietly mislead you, and how to connect sprint-level signals to what is actually happening in the code. This guide covers the essential metrics every agile team should track, the leadership-facing measures that tie value delivery to business goals, and the developer-productivity metrics that most project management tools can't capture.

What are agile metrics?

Agile metrics are quantitative measures that help development teams inspect and adapt how they plan, build, and ship software. They track project progress through a sprint, the flow of work across a board, product quality at release, and the predictability of the delivery process over time. Good agile metrics answer a single question: is the team getting better at delivering more value, and if not, where is the friction?

In practice, a healthy set of agile metrics might look like a sprint burndown chart that flattens mid-sprint because a dependency slipped, a cycle time trend showing pull requests now sit in review 40% longer than last quarter, and a Code Insights dashboard in Sourcegraph tracking how many services still depend on a deprecated authentication library the platform team is trying to retire. Each number points to a decision someone needs to make.

Why agile teams need metrics

Agile ceremonies (stand-ups, retrospectives, reviews) depend on shared observation. Without tracking metrics, retros turn into opinion matches. With them, the development team has evidence: velocity dropped for three sprints in a row, cycle time is creeping up on a specific service, and defects keep escaping from the same area of the codebase. That evidence drives continuous improvement, turning "we should do better" into "we should do this specific thing next sprint."

Metrics also give leadership a shared language with engineering, enabling teams to track progress against concrete goals rather than gut feel. A VP of Engineering who can show trend lines for delivery predictability and change failure rate has a much easier conversation with the CFO than one who has to describe "vibes."

Agile metrics vs. traditional project management KPIs

Traditional project management key performance indicators (earned value, schedule variance, cost performance index) assume a fixed scope and plan. Agile metrics assume the opposite: scope will change, the plan will adapt, and the measurement system has to accommodate that. Velocity isn't forecasting a deadline six months out; it's setting expectations for the next sprint or two. Cycle time isn't a contractual milestone; it's a signal of workflow efficiency.

The practical difference: traditional KPIs reward conforming to the plan. Agile methods reward continuous improvement. If your agile project's metrics punish changes in direction, they aren't agile key performance indicators.

Key agile metrics every team should track

These seven key metrics cover delivery, flow, and quality. Many agile teams don't need more, and teams that track too many metrics usually ignore all of them.

Metric	What It Measures	Best For	How to Calculate
Sprint Burndown	Work remaining vs. time in a sprint	Daily sprint tracking	Remaining work (story points or hours) plotted against days in the sprint
Velocity	Work completed per sprint	Capacity planning	Sum of story points completed, averaged over 3-5 sprints
Cycle Time	Time from work start to finish	Flow efficiency	End date minus start date, per ticket
Lead Time	Time from request to delivery	Responsiveness to customers	Delivery date minus request date
Cumulative Flow Diagram	Work distribution across states	Bottleneck detection	Stacked area chart of tickets by status over time
Escaped Defects	Bugs found after release	Quality	Count of production bugs traced to a given sprint or release
Work in Progress (WIP)	Items currently in flight	Focus and throughput	Count of tickets in "in progress" states

Sprint burndown

A sprint burndown chart plots remaining work against days left in the sprint. A healthy burndown trend is downward steadily. A chart that stays flat for days and then drops on the last afternoon tells you the team is batching work to the end of the sprint, which usually means review or QA is the bottleneck. For scrum teams, this is the most immediate visual representation of the team's progress through a sprint.

Watch for the shape, not just the final value. A flat-then-crash burndown hides problems that a steady slope would expose on day three.

Velocity

Velocity is the sum of story points (or number of tasks, if you don't estimate) a team completes per sprint, averaged over the last three to five sprints. It exists to help the team plan team capacity for the next sprint, not to compare teams against each other. Cross-team velocity comparisons are the single most common misuse of this metric, because two teams can estimate the same development effort at wildly different point values and both be internally consistent.

Sustained swings of 20-30% or more in a team's average velocity often indicate instability: estimation is inconsistent, scope is shifting mid-sprint, or people keep getting pulled to fight fires. Velocity is also less useful for teams working on interrupt-driven support or platform work, where the nature of the work is inherently unpredictable.

Cycle time

Cycle time measures how long a single piece of work takes from "started" to "done." It's more actionable than velocity because it focuses on individual items and helps identify bottlenecks in the development process. A team with a 5-day median cycle time and a P90 of 22 days has a long tail problem: most work moves fast, but a meaningful fraction gets stuck somewhere.

Break the cycle time down by state. If "in review" is half of the total cycle time, the bottleneck is code review, not coding. One pattern that comes up repeatedly: a team sees cycle time double over two months and assumes they need more engineers, when the real cause is a single overloaded reviewer blocking 60% of PRs. The metric surfaces the problem; the state-level breakdown tells you where to look.

Lead time

Lead time is broader than cycle time. It runs from the moment a request enters the backlog to the moment it ships to users. Lead time captures how responsive the team operates toward new requests, including the time spent actively working vs. the time work sits in the backlog before anyone starts it.

A short cycle time paired with a long lead time means the team executes fast once work starts, but has a prioritization or team capacity problem upstream.

Cumulative flow diagram

A cumulative flow diagram (CFD) stacks the count of tickets in each workflow state over time. In a healthy CFD, bands grow roughly in parallel. When one band (say, "in review") widens, that state is accumulating work faster than it's clearing, and you have a bottleneck.

CFDs are one of the most effective visualizations for identifying bottlenecks before they crater velocity.

Escaped defects

Escaped defects are bugs that reach production. Count them, group them by release or sprint, and look for patterns: which service, which kind of change, which team. A spike in escaped defects after a release usually traces back to skipped review, a compressed timeline, or a risky refactor with thin test coverage.

This is where agile metrics start to need code-level visibility. A ticket count won't tell you that escaped defects cluster in code paths with no test coverage, or that 70% of them touched the same three files. For that, you need to look at the code itself, which is where tools like Sourcegraph Code Search come in for root-cause analysis.

Work in progress (WIP)

Work in progress (WIP) counts how many tasks are currently in flight. High WIP correlates with long cycle time (Little's Law: as WIP increases without a corresponding increase in throughput, cycle time grows). Most Kanban teams set explicit WIP limits per column and treat breaching the limit as a signal to stop starting new work and help finish completed tasks first. This lean metrics approach directly improves team efficiency: lower WIP, faster flow.

Agile metrics for leadership

The metrics above help agile teams monitor progress at the sprint level. Leadership and project managers need a different cut: metrics that connect delivery to business goals and make a team's performance legible to the rest of the organization.

Delivery predictability

Delivery predictability measures the gap between what the team committed to and what it delivered, usually as a percentage across a quarter or release. A team hitting 85-95% of committed scope is healthily predictable. A team hitting 110% is probably padding commitments. A team hitting 60% is either over-committing or getting pulled off-plan repeatedly.

This metric matters to leadership because it's the foundation of every roadmap promise and release plan. Without predictability, dates are guesses, and planning agile initiatives across quarters is theater.

Value delivered per sprint

Value delivered is harder to quantify than velocity, because "value" depends on who you ask. Many teams proxy it by tagging tickets to outcomes: what percentage of completed work maps to revenue features vs. reliability work vs. internal tooling? One approach is tracking the ratio of roadmap items shipped to unplanned work absorbed. It's imperfect, but it answers the question velocity can't: are we shipping the right things?

Team health and morale

Tracking team happiness is typically done through short, anonymous pulse surveys run each sprint or month, covering workload, clarity, psychological safety, and confidence in direction. Team morale is a leading indicator: it drops before delivery does. Watch for pager load, chronic sprint spillover, and review burden as early signals. A VP of Engineering watching team happiness trend down has weeks to intervene before velocity follows.

Customer satisfaction metrics

NPS and customer satisfaction scores (CSAT) close the satisfaction loop, while feature adoption rates and customer feedback help validate whether shipped work is actually being used. A team can be shipping on time, with low cycle time and strong product quality, and still be building the wrong thing. These metrics provide insights into whether the output matters.

Developer productivity metrics in agile

Traditional agile metrics describe what the team ships. Developer productivity metrics describe how the agile development process works at the code level. The two sets are complementary, and engineering leaders increasingly need both. The DORA metrics are the most widely adopted delivery-performance framework. They are best known for deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time, with more recent DORA research also incorporating reliability as an additional dimension. Microsoft Research's SPACE framework expands the lens further to include satisfaction, performance, activity, communication, and efficiency.

Code review turnaround time

Code review turnaround is the time a pull request spends waiting for review and approval. It's often the single largest contributor to cycle time in organizations that use pull-request-based workflows, and a keen focus area for agile practitioners looking to streamline processes. Long review times usually mean one of three things: reviewers are overloaded, the PRs are too large, or there's no clear ownership over who reviews what.

AI coding assistants are starting to help here. Tools like Sourcegraph's Cody can generate PR context, explain unfamiliar code paths, and help reviewers get up to speed on changes they didn't write, which compresses the part of the review that isn't about judgment but about orientation.

Deployment frequency

Deployment frequency counts how often code ships to production. High-performing teams in the DORA research tend to deploy on demand, often multiple times per day, while low-performing teams deploy far less frequently, sometimes monthly or less. Frequency isn't a vanity number. Teams that deploy more frequently usually do so by shipping smaller changes, which are easier to validate, rollback, and recover from when something goes wrong.

Change failure rate

Change failure rate is the percentage of deployments that cause an incident, require a hotfix, or get rolled back. DORA research shows elite performers maintain low change failure rates, often in the low double digits or below, while consistently higher rates typically indicate teams are shipping too much at once, skipping tests, or lacking good rollback mechanisms.

Mean time to recovery (MTTR)

MTTR measures how long it takes to restore service after a production incident. DORA has since refined this to "failed deployment recovery time" for deployment-specific incidents, but the underlying idea is the same: when things break, how fast do you recover? MTTR is often a better indicator of operational maturity than any pre-production metric.

Code-level visibility matters here. When an incident hits, engineers have to locate the offending change, understand its blast radius, and ship a fix or rollback. Sourcegraph Code Search lets engineers search every repository at once to find the exact code path implicated in an incident, which can significantly reduce the time spent understanding the problem. When the fix is systemic (every service using a bad library version, for example), Batch Changes can apply the fix across hundreds of repositories in a single operation instead of filing 200 individual PRs.

For a deeper look at developer productivity measurement, see our guide on measuring developer productivity.

Agile metrics anti-patterns

Even with the right agile metrics in place, teams can misuse them in predictable ways. These are the three worst anti-patterns.

Using metrics as a stick (Goodhart's law)

Goodhart's Law says that when a measure becomes a target, it stops being a good measure. Turn velocity into a performance target, and teams will inflate estimates. Turn the closed-ticket count into a bonus metric, and tickets will get split into pieces. Turn code review turnaround into a KPI, and reviews will become rubber stamps.

Metrics should inform data-driven decision-making, not drive compensation. The moment a metric shows up in a performance review, it stops being trustworthy.

Measuring individuals instead of teams

Agile work is teamwork. Measuring individual velocity or individual ticket counts punishes the developer who spent three days enabling teams by unblocking colleagues, mentoring a junior, or fixing the flaky test suite that was costing everyone time. None of that shows up in individual throughput, and all of it strengthens team collaboration.

Measure the team. If an individual is genuinely underperforming, use direct observation and feedback, not metrics trickery.

Vanity metrics vs. actionable metrics

A vanity metric looks good in a slide but doesn't change any decision. "Total story points completed this year" is a vanity metric. "Cycle time by service, segmented by change type" is actionable. The test: if the number goes up or down by 20%, does someone do something different tomorrow? If not, stop tracking performance on that dimension.

How to build an agile metrics dashboard

Most teams start with a dashboard that copies every chart their project management tool offers and wonder why nobody looks at it. No single dashboard will capture overall project health perfectly; the goal is to assemble a small set of signals that help teams ask better questions. In practice, that means five to seven metrics, each tied to a specific question the team actually asks.

Choosing the right metrics for your team

Start from questions, not metrics. What does the team want to know? Choosing the right agile metrics means asking: Are we getting faster? Are we shipping quality? Are we predictable? Where do we get stuck? Pick one metric per question. For scrum teams, that might be velocity, cycle time, escaped defects, delivery predictability, and cumulative flow. For Kanban teams, swap velocity for throughput and add WIP. Either agile framework benefits from a keen focus on the metrics that actually measure progress.

Revisit the set every quarter. Metrics that stop driving conversations should get pruned.

Tools for tracking agile metrics

Project management tools (Jira, Azure DevOps, Linear) cover tracking agile metrics at the sprint level natively: burndown, velocity, cycle time, CFDs. For DORA metrics, teams typically add a CI/CD-aware layer (LinearB, Swarmia, DX, or open-source options like Four Keys). For team health, lightweight pulse survey tools (CultureAmp, Officevibe, or Google Forms) do the job.

The common gap: none of these tools sees what's happening in the code itself. They see the metadata around the code (PR titles, merge times, deploy events), but not the code's structure, dependencies, or evolution.

Integrating code-level insights into agile dashboards

Code-level insights are the layer most agile dashboards miss. Examples of metrics that live in the code, not in Jira:

• Migration progress: how many services have been moved off a deprecated library
• Code smells: count of TODOs, deprecated function calls, or known anti-patterns across the codebase
• Library adoption: how many repositories use the new internal SDK
• Test coverage trends: coverage delta per service, per sprint
• Technical debt hot spots: files with high churn and low test coverage

Sourcegraph Code Insights exists to track these signals. It treats code as a queryable dataset, so a platform team can watch migration progress across 400 repositories on a single chart, or track the number of services still calling a deprecated API as a trend line. Plugged into the same dashboard as Jira velocity and CFD, it gives engineering leaders a complete picture: what the team planned to ship, what it actually shipped, and what's happening in the code underneath.

That's the combination that turns tracking agile metrics from a reporting exercise into a tool for data-driven decision-making.

Conclusion

Agile metrics work when they drive decisions and fail when they become targets. The strongest engineering leaders combine delivery-focused scrum metrics (velocity, cycle time, predictability) with code-level signals (review turnaround, deployment frequency, migration progress, code health) to get a complete picture of how the team ships and where to drive continuous improvement. Jira tells you what got done. Code-level insights tell you why it happened, and what risks are building underneath.

If you're building out an agile metrics dashboard and want the code-level layer that traditional project management tools can't see, explore Sourcegraph Code Insights and see what your codebase looks like as a queryable dataset.

Frequently asked questions

What are the 5 most important agile metrics? For most teams: sprint burndown, velocity, cycle time, escaped defects, and delivery predictability. Add DORA metrics (deployment frequency, change failure rate) if you deploy frequently enough for them to be meaningful.

What is velocity in agile? Velocity is the sum of story points (or tickets) a team completes per sprint, averaged over the last three to five sprints. It's used for capacity planning within a team, not for comparing teams.

How do you measure agile team performance? Use a small set of quality metrics that cover speed (cycle time, velocity), product quality (escaped defects, change failure rate), predictability (delivery predictability), and team health (pulse surveys). No single metric captures a team's performance; the combination does.

What are DORA metrics in agile? DORA has identified five software delivery performance metrics: deployment frequency, lead time for changes, change failure rate, failed deployment recovery time, and reliability. They come from the DevOps Research and Assessment group's work on what distinguishes elite-performing engineering organizations.