Agile Metrics: What to Track and Why They Matter (2026)
Agile metrics help teams improve delivery speed, quality, and predictability when you track the right signals and act on them.

Agile metrics help teams improve delivery speed, quality, and predictability when you track the right signals and act on them.
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.
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.
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."
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.
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 |
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 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 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 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.
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 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) 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.
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 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 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?
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.
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.
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 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 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 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.
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.
Even with the right agile metrics in place, teams can misuse them in predictable ways. These are the three worst anti-patterns.
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.
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.
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.
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.
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.
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.
Code-level insights are the layer most agile dashboards miss. Examples of metrics that live in the code, not in Jira:
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.
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.
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.

With Sourcegraph, the code understanding platform for enterprise.
Schedule a demo