The engineering metrics glossary

Lead Time

Lead time = completed date − created date

The elapsed time from when a work item is requested until it is delivered — including all the time it sits in a backlog before anyone touches it. Lead time is the customer's experience of your delivery speed: they don't care when you started, only when they asked and when they received.

Long lead times combined with short cycle times mean work waits in queues, not that engineers are slow. That distinction changes the fix from "push harder" to "start less, finish more".

In TheMetrics: computed per task from ClickUp status history and sliced by team, list, and sprint. See where delivery gets stuck.

Cycle Time

Cycle time = completed date − first in-progress date

The elapsed time from when work actually starts until it is done. Cycle time is the core flow metric: the shorter and more stable it is, the more reliable your forecasts and the faster your feedback loops. Teams with predictable cycle times can commit to dates with confidence; teams without them are guessing.

Confusing cycle time with lead time is the most common metrics mistake in engineering orgs — we wrote a full breakdown in Cycle Time vs Lead Time.

In TheMetrics: tracked per workflow status so you can see exactly which stage stretches the total. Explore flow control.

Throughput

Throughput = items completed ÷ time period

The number of work items a team finishes per week or sprint, counted in items rather than story points — which makes it immune to estimation inflation. Throughput is the pace signal you can actually trust, and it is the input distribution for Monte Carlo forecasting.

Little's Law ties the flow metrics together: average WIP = throughput × average cycle time. If two of them move, the third has already moved.

In TheMetrics: trended by team and work type, and fed directly into delivery forecasts.

Work in Progress (WIP) / Inventory

Everything that has been started but not finished. Each open item is capital invested with no return yet — plus a context-switching tax on the people juggling it. Rising inventory with flat throughput is the earliest warning sign of a slipping roadmap, visible weeks before any deadline is missed.

In TheMetrics: inventory levels by status and team, with alerts when WIP outruns capacity. See the delivery ledger.

Bottleneck Analysis

Breaking cycle time down by workflow status to find where work waits longest. The status with the longest average wait — usually code review or QA, not development — is the system constraint. The theory of constraints says improving anything other than the bottleneck just piles up more inventory in front of it.

In TheMetrics: a per-status wait-time breakdown that names the constraint, so you fix the queue instead of blaming the team. Explore flow control.

Velocity

Velocity = story points completed per sprint

The classic Scrum metric. Velocity is useful inside one team for capacity planning — "we average 42 points, so don't commit to 60". It is meaningless for comparing teams, because a story point in one team is not the same unit as a story point in another, and it inflates the moment it becomes a target (Goodhart's law).

Watch the trend and the stability, not the absolute number. A velocity that swings ±40% sprint to sprint is telling you the estimates or the scope are unstable.

In TheMetrics: velocity with planned-versus-delivered overlays per sprint, plus the cost side of each point. See cost visibility.

Story Point Cost (SP Cost)

SP cost = loaded engineering cost per period ÷ points delivered per period

What one story point costs in payroll terms. Once you know a point costs, say, $700, every backlog becomes a budget conversation: a 120-point epic is an ~$84,000 decision, and "should we build this?" gets a denominator. It also exposes when delivery cost per unit is drifting up quarter over quarter.

In TheMetrics: computed from ClickUp delivery data plus your salary and capacity model — no timesheets. See what roadmap items cost.

Cost per Feature / Cost Analysis

The engineering spend behind a specific feature, epic, or milestone, calculated by rolling task effort and loaded rates up the work hierarchy. This is the answer to the board question "what did that cost us?" — with a distribution and outliers, not a shrug. Comparing cost per feature against impact is how roadmap prioritization becomes an investment decision.

In TheMetrics: average task, feature, and milestone cost with outlier detection. See cost tracking in depth.

Engineering Operating Expenses

The loaded cost baseline of the engineering organization — salaries, benefits, tooling, infrastructure, overhead — allocated across teams and initiatives. It is the denominator behind story point cost and cost per feature: without a real OpEx model, every "cost" number downstream is fiction.

In TheMetrics: a capacity-aware OpEx model that allocates spend to the work actually delivered. Explore cost visibility.

Monte Carlo Forecast

A delivery forecast produced by simulating thousands of possible futures from your historical throughput distribution, instead of adding up estimates. Each simulation asks "if the next weeks look statistically like the last ones, when does this scope finish?" — and the result is a probability curve of completion dates, not a single made-up one.

Monte Carlo needs no estimates at all: item counts and historical throughput are enough, which removes the estimation theater from date-setting.

In TheMetrics: run automatically per milestone from ClickUp history. See will the milestone land?

P50 and P85 Confidence Dates

Percentile readings of the forecast distribution. The P50 date is a coin flip — half of the simulated futures finish by then. The P85 date is the one you can commit to externally: 85% of futures land on or before it. Quoting P50 dates to customers is how teams end up "always late" while technically forecasting correctly.

The gap between P50 and P85 measures your uncertainty. Shrinking that gap — by stabilizing flow, not by estimating harder — is what makes an organization predictable.

In TheMetrics: every milestone shows P50 and P85 side by side, with the risk drivers underneath. See milestone forecasting.

Burn-up Chart

A chart of completed scope against total scope over time. Unlike the classic burn-down, a burn-up makes scope creep visible: when the target line rises, you can see that the goalposts moved — instead of wondering why the burn-down never reaches zero. The slope is your pace; where the lines intersect is your landing date.

In TheMetrics: burn-up patterns per milestone with delivery risk signals when pace and scope diverge. See milestone tracking.

DORA Metrics (the four keys)

Four measures identified by the DevOps Research and Assessment program as the best predictors of software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. Together they balance speed (the first two) against stability (the last two) — so you can't game one without the other showing it.

DORA's yearly research groups teams into elite, high, medium, and low performers, which makes the four keys the closest thing engineering has to a standardized benchmark.

In TheMetrics: all four keys derived from GitLab pipelines and merge requests, benchmarked and trended. See DORA metrics for GitLab.

Deployment Frequency

How often code is successfully released to production. Frequent, small deployments mean smaller blast radius, faster feedback, and less painful rollbacks. Commonly cited elite benchmark: deploying on demand, often multiple times per day; low performers ship between once a month and once every six months.

In TheMetrics: counted from successful GitLab production pipelines, per project and team.

Lead Time for Changes

The time from code committed to code running in production. This measures the delivery pipeline only — review, CI, approvals, release — unlike customer lead time, which starts at the request. Commonly cited elite benchmark: under one day. Long lead time for changes usually points at review queues and release ceremony, not coding speed.

In TheMetrics: derived from GitLab commit and deployment timestamps, with the wait stages broken out.

Change Failure Rate

CFR = failed deployments ÷ total deployments

The percentage of production deployments that cause a failure requiring a hotfix, rollback, or patch. It is the stability counterweight to deployment frequency: shipping constantly is only impressive if things don't constantly break. Commonly cited elite benchmark: under 15%.

In TheMetrics: tracked from GitLab deployment outcomes and incident-labeled follow-ups.

Time to Restore Service (MTTR)

How long it takes to recover when a deployment fails or production breaks. Elite performers restore service in under an hour, because they optimize for recovery speed rather than pretending failures won't happen. A healthy MTTR is what makes a high deployment frequency safe.

In TheMetrics: measured from failure detection to the restoring deployment in GitLab. See GitLab DORA metrics.

Defect Leakage Rate (DLR)

Weighted DLR = Σ(defect tasks × priority weight) ÷ (Σ(defect tasks × priority weight) + non-defect tasks delivered) × 100

Of the tasks completed in the period, how much was fixing defects rather than delivering new work. A task counts as a defect when it carries one of the configured defect tags (by default: bug, incident, reqFix, devFix). Defects are weighted by priority — by default Urgent 3, High 2, Normal 1, Low 0.5 — so one urgent production bug weighs as much as three normal ones.

Lower is better. The weighting keeps a pile of cosmetic low-priority fixes from looking as bad as a handful of urgent incidents.

In TheMetrics: a KPI card on the Allocation page, with a per-sprint DLR chart beneath it. Defect tags and priority weights are configurable. DLR is 50% of the Quality dimension of the Organization Health Score.

Rework Rate

Rework rate = tasks that came back after entering QA ÷ tasks that entered QA × 100

Of the tasks completed in the period that went through QA, how many were sent back. A task is reworked when, after entering a QA (gate) status, it later entered a return status — by default, any development status. QA → blocked → development counts; so does a reopen after release. Each task counts once, however many times it bounced.

Because it is read from status history rather than bug tickets, rework rate cannot be lowered by not filing bugs — which makes it the honest check on DLR. When nothing entered QA in the period, it shows no data rather than 0%. It is a task-level measure, distinct from the merge-request rework some DORA tooling reports.

In TheMetrics: a KPI card on the Allocation page, derived automatically from ClickUp status history, with configurable gate and return statuses. Rework rate is 30% of the Quality dimension of the Organization Health Score.

Defect Share of Capacity

Defect share = story points of defect-tagged tasks completed ÷ story points of all tasks completed × 100

A measure of capacity, not ticket count: how much of the team's delivered effort went to fixing defects rather than creating new value. Ten tiny bug tickets and one large one tell very different stories; story points tell them apart.

If defects are not sized with story points, it shows no data rather than 0% — unsized bugs still consumed capacity, and reporting them as free would flatter the number.

In TheMetrics: a KPI card on the Allocation page, computed from the configured QA tags (by default: bug, devFix). Defect share is 20% of the Quality dimension of the Organization Health Score.

SPACE Metrics

A productivity framework from Microsoft Research and the DORA team built on one finding: no single metric captures developer productivity. SPACE stands for Satisfaction, Performance, Activity, Communication, and Efficiency of flow — and prescribes measuring across at least three dimensions so that optimizing one (activity, usually) can't quietly wreck the others.

In TheMetrics: a SPACE-aligned scorecard combining delivery data with survey signals. See organization health.

Gini Index (Work Concentration)

A measure borrowed from economics: how evenly is completed work distributed across the team? 0 means perfectly even; 1 means one person does everything. A high Gini index is a bus-factor risk (knowledge concentrating in one head), a burnout signal for the person carrying the load, and a growth blocker for everyone else on the team.

In TheMetrics: computed over task-completion distribution per team, trended so you can see concentration building before it hurts. See org health.

Engineering Capacity

The engineer-time genuinely available for planned work per period — after meetings, interviews, support rotations, and leave. Plans built on headcount instead of capacity are optimistic by 20–40% before the first line of code. Capacity is also the denominator that makes cost allocation honest.

In TheMetrics: a per-team capacity model that feeds both forecasts and cost metrics. See people & capacity.

Organization Health Score / KPI Scores

A composite scorecard that combines flow, delivery, cost, and people metrics into one trendable index. The point is not the single number — it's the conversation structure: every input is visible, weighted, and traceable back to raw ClickUp and GitLab data, so "engineering is doing fine" becomes an auditable claim instead of a vibe.

In TheMetrics: configurable KPI scorecards that roll up into executive reports that survive follow-up questions.