Engineering glossary

This glossary defines 24 terms engineering leaders use to describe delivery, predictability, AI contribution, and code quality, with the 2026 benchmark band attached wherever one exists. Definitions carry a band because a term without a threshold cannot settle an argument. Every figure comes from 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, aggregated at the 75th percentile. Each entry links to the full explanation of that term.

Metric definitions carry more weight than they appear to, because two teams using the same word for different measurements cannot compare results. The SPACE paper in Communications of the ACM makes the related argument that no single dimension describes productivity on its own. For the full band tables behind the entries below, see engineering metrics benchmarks.

An engineering metric is a measurement of how software gets delivered, and an engineering benchmark is the band that shows where a given value sits relative to a community of teams. A definition without a band describes the measurement, and a band without a definition invites the wrong comparison.

Cycle time

Cycle time is the time for a single engineering task to move through the delivery phases from code to production. Elite is under 25 hours at the 75th percentile and the lowest tier runs beyond 161 hours. See cycle time for the calculation and phase breakdown.

Coding time

Coding time is the time from first commit until a pull request is published. Elite is under 54 minutes at the 75th percentile. Short coding time correlates with low work in progress, small pull requests, and clear requirements.

Pickup time

Pickup time is the time a pull request waits for someone to start reviewing it. Elite is under one hour at the 75th percentile and the lowest tier runs beyond 16 hours. Low pickup time reflects a healthy review process rather than individual reviewer speed.

Review time

Review time is the time to complete a code review and get a pull request merged. Elite is under three hours at the 75th percentile. Approve time and merge time are its two more granular segments. See code review best practices for the practices behind the number.

Approve time and merge time

Approve time is the time from first comment to first approval, with elite under 10 hours. Merge time is the time from first approval to merge, with elite under one hour. Together they show whether a slow review is a discussion problem or a merge-gate problem.

Deploy time

Deploy time is the time from when a branch is merged to when code is released. Elite is under 16 hours at the 75th percentile and the lowest tier runs beyond 277 hours, the widest spread of any delivery metric. Low deploy time correlates with high deploy frequency.

Merge frequency

Merge frequency is the total pull requests a team merges over a period, expressed per developer per week. Elite is above 2.0 and the lowest tier falls below 0.66. The band is identical across every percentile, since merge frequency is a rate metric.

Deploy frequency

Deploy frequency is how often code is released, measured per service. Elite is above 1.2 and the lowest tier falls below 0.2. It is one of the four measures in the 2025 DORA State of AI-assisted Software Development report. See DORA metrics.

Pull request

A pull request is a proposed set of code changes submitted for review before merging into a shared branch. It is the unit almost every delivery metric is measured against, which makes it the smallest useful object for engineering measurement. See what is a pull request.

PR size

PR size is the number of code lines modified in a pull request. Elite is under 100 lines at the 75th percentile and the lowest tier runs beyond 228. Smaller pull requests are easier to review, safer to merge, and correlate with lower cycle time.

PR maturity

PR maturity is the ratio between changes added to a branch after the pull request was published and the total changes in the pull request. Elite is above 89% and the lowest tier falls below 77%. A low figure means reviewers are chasing a moving target.

Change failure rate

Change failure rate is the percentage of deploys that cause a production failure. Elite is under 1% and the lowest tier runs above 17%. The band is identical across every percentile. See change failure rate.

Rework rate

Rework rate covers changes to code less than 21 days old. Elite is under 3% and the lowest tier runs above 8%. A high rework rate signals churn and functions as a leading indicator of quality problems.

Refactor rate

Refactor rate covers changes to legacy code, defined as code in the codebase more than 21 days. Elite is under 11% and the lowest tier runs above 22%. Read alongside rework rate, it shows whether a team tends existing code or only adds new paths.

Planning accuracy

Planning accuracy is the ratio of planned work to work delivered during a sprint or iteration. Elite is above 82% and the lowest tier falls below 47%. High planning accuracy signals stable execution rather than conservative planning.

Capacity accuracy

Capacity accuracy is all completed work, planned and unplanned, as a ratio of planned work. Elite sits between 85% and 115%, and the lowest tier falls below 70% or exceeds 130%. Read with planning accuracy, a figure above 115% indicates the plan was too small.

MTTR

MTTR is the mean time to restore service after a production failure. It carries no 2026 benchmark band, because teams start the recovery clock at different events and scope incidents differently, so cross-organization comparison is invalid. Track it against your own internal trend.

Agentic AI pull request

An agentic AI pull request is created by an AI agent such as Devin, Copilot Coding Agent, or OpenAI Codex, where the agent interprets a task, generates code, commits, and opens the pull request. Agentic pull requests wait 17.6 hours before pickup at the 75th percentile against 3.4 hours for unassisted work. See how agentic AI disrupts the software delivery lifecycle.

AI-assisted pull request

An AI-assisted pull request is human-authored and shaped by AI, with the developer keeping control and ownership. AI-assisted pull requests are the largest of the three types, reaching 408 lines at the 75th percentile against 157 for unassisted work.

Unassisted pull request

An unassisted pull request is authored entirely by a developer without substantial AI use. Unassisted work carries the highest refactor rate at 0.37 at the 75th percentile, more than 1.5x either AI category, so it touches existing code at a higher rate.

Acceptance rate

Acceptance rate is the percentage of pull requests merged within 30 days of creation or of moving out of draft. Manual pull requests merge at 84.4% against 32.7% for AI pull requests. Reaching elite takes above 95% for manual work and just above 71% for AI work. See how to measure generative AI code.

Code churn

Code churn is code that gets rewritten or deleted shortly after being written. High churn on recent code indicates unclear requirements rather than poor craft. See what is code churn.

Cyclomatic complexity

Cyclomatic complexity counts the independent paths through a piece of code, which sets the minimum number of tests needed to cover it. See cyclomatic complexity.

Technical debt

Technical debt is the future cost created by choosing a faster implementation over a more maintainable one. It behaves like debt because the interest is paid in every subsequent change to the same code. See handling technical debt in scrum.

Code coverage

Code coverage is the share of code executed by an automated test suite, and branch coverage is the stricter variant that requires every decision path to run. Neither measures whether the tests assert anything useful. See code coverage types.

Quality gate

A quality gate is an automated check a change must pass before progressing, such as a coverage threshold, a lint rule, or a security scan. Gates enforce standards without adding a human review step. See quality gates.

What percentile do these benchmark bands use?

Every band on this page uses the 75th percentile, which LinearB's 2026 Software Engineering Benchmarks Report uses by default because it resists outliers. Only time metrics and pull request size change with percentile, since rate and ratio metrics publish a single band across average, 50th, 75th, and 90th percentiles.

What do the benchmark tiers mean?

Elite covers 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 standard of quality.

Why does MTTR have no benchmark band?

A metric earns a published band when its definition holds across organizations. MTTR fails that test, because teams measure recovery from different starting points and across different incident scopes, so it appears here as a definition without a band.

Can AI and manual pull request figures be combined?

No. Agentic, AI-assisted, and unassisted pull requests are distinct categories with different size, pickup, review, and refactor profiles, so a blended figure describes none of them. Keep the three separate in any report or comparison.

Get the full band tables

Every figure on this page comes from one source. The 2026 Software Engineering Benchmarks Report carries the complete tables by metric, percentile, and organization size, plus the AI insights behind the contribution-type entries.