Summary
- Engineering metrics group into three categories: delivery, predictability, and project management, with AI metrics added to the 2026 set.
- Benchmark tiers show community position, not absolute quality: elite is the top 10%, needs improvement is the bottom 40%, per LinearB's 2026 Benchmarks Report.
- Rate and ratio metrics like change failure rate and planning accuracy publish one band across every percentile; time metrics and PR size change with percentile.
- MTTR was removed from the 2026 benchmarks since teams measure recovery from different starting points; track it against your own trend instead.
What are engineering metrics?
Engineering metrics are the measurements that describe how an engineering organization turns work into software running in production, and they group into three categories: delivery, predictability, and project management. A metric earns its place by changing a decision. LinearB's 2026 Software Engineering Benchmarks Report, built from more than 8.1 million pull requests from 4,800 teams and 163,820 contributors across 42 countries, publishes 20 metrics across those categories plus new AI metrics. This page sets out the categories, how to read a benchmark tier correctly, which metrics mislead, and how to choose the four that should run your review cadence.
The metric list is the easy half. Reading the numbers correctly is where programs fail, and percentile choice is the first place it happens. For the tier-by-tier view of what separates top performers, see engineering metrics benchmarks.
Engineering metrics are measurements of how an engineering organization delivers software, covering delivery flow, predictability of commitments, and project management hygiene. A metric is useful when it identifies where work stops and prompts a specific action.
The three categories, and what belongs in each
Delivery metrics measure how work moves, predictability metrics measure whether commitments hold, and project management metrics measure whether the work is traceable. Delivery covers coding time, pickup time, approve time, merge time, review time, deploy time, cycle time, merge frequency, deploy frequency, pull request size, and pull request maturity. Predictability covers change failure rate, refactor rate, rework rate, capacity accuracy, and planning accuracy. Project management covers issues linked to parents, branches linked to issues, in-progress issues with estimation, and in-progress issues with assignees.
Two definitions carry more weight than the rest because they behave as leading indicators. Rework rate covers changes to code less than 21 days old, and a high rework rate signals churn ahead of a quality problem. Refactor rate covers changes to code older than 21 days, which describes how much attention existing code receives. For the working metric list in dashboard form, see the engineering metrics dashboard and engineering KPIs.
What to do next: Sort your current metric list into the three categories. A list with nothing in the predictability column explains why delivery speed improvements never reach the executive conversation intact.
How to read a benchmark tier without misreading it
A benchmark tier describes where a team sits in a community rather than an absolute standard of quality. In LinearB's 2026 Software Engineering Benchmarks Report, elite covers the top 10% of the LinearB community, good covers the top 30%, fair covers the top 60%, and needs improvement covers the bottom 40%. Reading elite as a pass mark rather than a position produces targets that no phase of your pipeline needs to hit.
| Tier | Definition |
|---|---|
| Elite | Top 10% of the LinearB community |
| Good | Top 30% of the LinearB community |
| Fair | Top 60% of the LinearB community |
| Needs improvement | Bottom 40% of the LinearB community |
Three reading rules keep a comparison honest. First, the 2026 benchmarks aggregate at the 75th percentile, chosen because it resists outliers, so a figure quoted at a different percentile is not comparable to the published band. Second, rate and ratio metrics publish a single band across average, 50th, 75th, and 90th percentiles, which covers merge frequency, deploy frequency, pull request maturity, change failure rate, refactor rate, rework rate, capacity accuracy, planning accuracy, and all four project management metrics. Only time metrics and pull request size change with percentile. Third, compare against your organization size band, since enterprise teams above 1,000 employees reach elite cycle time under 27 hours against under 25 hours for the full data set.
What to do next: Write the percentile next to every benchmark figure in your internal reporting. An unlabeled number invites a comparison against the wrong band.
Project management metrics, the category teams skip
Project management hygiene decides whether any other metric can be trusted, because a branch with no linked issue cannot be attributed to a team, a project, or an outcome. The 2026 bands for this category publish at the organization level only, without a breakdown by size.
| Metric | Elite | Good | Fair | Needs improvement |
|---|---|---|---|---|
| Issues Linked to Parents (%) | > 90% | 90 - 67% | 66 - 56% | < 56% |
| Branches Linked to Issues (%) | > 77% | 77 - 62% | 61 - 41% | < 41% |
| In Progress Issues with Estimation (%) | > 55% | 55 - 26% | 25 - 14% | < 14% |
| In Progress Issues with Assignees (%) | > 96% | 96 - 84% | 83 - 76% | < 76% |
The estimation band shows how uneven this practice is, with elite starting above 55% and the good tier running all the way down to 26%. A team at 30% estimation coverage sits inside the good tier while three in four of its in-progress issues carry no estimate, which is the kind of finding that only appears when you look at the band rather than the label.
What to do next: Check branches linked to issues first. If it sits below 62%, fix traceability before you invest in any delivery metric target, because the attribution underneath it will not hold.
APEX: choose four metrics in four steps
APEX is LinearB's operating model for engineering productivity, and it exists to keep a measurement program to four decisions. Each pillar carries one north star metric, with AI-assisted pull requests for AI leverage, planning accuracy and capacity accuracy for predictability, cycle time and change failure rate for efficiency, and a survey-based index for developer experience. The full model is in the APEX framework.
- Anchor on one north star per pillar, and name an owner for each of the four.
- Decompose the efficiency north star into its phases, because cycle time as a total cannot tell you which handoff to change.
- Benchmark each number against the band for your organization size, and record the gap in the metric's own units.
- Automate the response for the phase with the largest gap, then re-measure after one full sprint before adding another metric.
APEX builds on the published frameworks rather than replacing them. It incorporates the seven organizational capabilities from DORA's 2025 research as diagnostic survey questions inside the developer experience pillar, and it operationalizes the multi-dimensional principle set out in the SPACE paper in Communications of the ACM. The 2025 DORA State of AI-assisted Software Development report supplies the finding that connects the two, which is that AI amplifies the capability an organization already has.
What to do next: Cut your metric list to four north stars with four named owners this quarter. Every metric beyond those four needs to earn its place by naming the decision it changes.
Metrics that mislead, and what to use instead
Four measurements produce confident charts and poor decisions, and three of the four are still in wide use. The table pairs each one with the metric that answers the same question without the distortion.
| Misleading metric | Why it distorts | Use instead |
|---|---|---|
| Lines of code per developer | Inflates with generated code, and AI-assisted pull requests already run 2.6x larger than unassisted ones at the 75th percentile | Acceptance rate and cycle time by phase |
| Story point velocity | Measures an estimate rather than delivery, and the unit is not comparable between teams | Planning accuracy and capacity accuracy read together |
| Individual output ranking | Measures activity rather than delivered change, and damages the trust the data depends on | Team-level flow metrics, with individual data used for coaching only |
| Composite productivity scores | Hides which input moved, so no action follows from a change in the number | One north star per pillar, each traceable to a phase |
A related case is worth knowing because it shows how a metric can be sound and still not benchmarkable. MTTR was removed from the 2026 published benchmarks, not because recovery stopped mattering, but because teams measure it from different starting points and across different incident scopes, so the cross-organization comparison is invalid. Track MTTR against your own trend. For the velocity argument in full, see why agile velocity is the most dangerous metric.
What to do next: Remove composite scores and per-developer counts from every report that reaches leadership. Replace each one with the phase-level metric that shows where the work stopped.
What changes with AI in the metric set
Acceptance rate is the metric the 2026 report added for AI, and it measures the share of pull requests merged within 30 days of creation. Manual pull requests merge at 84.4% against 32.7% for AI pull requests. The elite threshold differs by contribution type as well, sitting above 95% for manual pull requests and just above 71% for AI pull requests, so a single acceptance target across both would either flatter one or penalize the other.
Two rules keep AI metrics accurate. Keep agentic, AI-assisted, and unassisted pull requests separate in every report, since their size, pickup, review, and refactor profiles differ. And attach an acceptance figure only to the 30-day merge window it was measured in. These relationships are correlational and align with LinearB's qualitative research over the past year. For the full data set, see the 2026 Software Engineering Benchmarks Report.
What to do next: Add acceptance rate to your reporting, segmented by contribution type, and label the 30-day window in the metric name so nobody re-cuts it against a different window.
Frequently asked questions
What are engineering metrics?
Engineering metrics are measurements of how an engineering organization delivers software, grouped into delivery metrics such as cycle time, predictability metrics such as planning accuracy and change failure rate, and project management metrics such as branches linked to issues. The 2026 published set covers 20 metrics plus new AI metrics.
What are the most important engineering metrics to track?
Track four north stars rather than a full list: AI-assisted pull requests for AI leverage, planning accuracy for predictability, cycle time decomposed by phase for efficiency, and a survey-based index for developer experience. Four metrics with named owners and review intervals produce decisions, while twenty produce reports.
What percentile should engineering benchmarks use?
Use the 75th percentile. LinearB's 2026 Software Engineering Benchmarks Report aggregates at the 75th percentile because it resists outliers, which makes comparison across organizations more reliable. Only time metrics and pull request size change with percentile, since rate and ratio metrics publish a single band.
What does the elite tier mean in engineering benchmarks?
Elite means the top 10% of the LinearB community for that metric. Good covers the top 30%, fair covers the top 60%, and needs improvement covers the bottom 40%. The tiers describe relative position rather than an absolute quality standard.
Why is MTTR not in the 2026 engineering benchmarks?
MTTR was removed because of definitional variance rather than a change in performance. Teams measure recovery from different starting points and across different incident scopes, so the numbers are not comparable across organizations. Track MTTR against your own internal trend instead of an industry band.
Should engineering metrics be used in performance reviews?
No. Individual output counts measure activity rather than delivered change, and using them in reviews damages the data quality the program depends on. Use team-level and system-level metrics for performance discussion, and give individuals their own data for coaching context.
Compare your metrics against 8.1 million pull requests
Pick your four north stars, then find out where they sit. The 2026 Software Engineering Benchmarks Report gives the bands by metric and organization size, and engineering metrics in LinearB shows the same numbers against your own pipeline with benchmarks in the view.