Engineering efficiency is how much finished, working product a team delivers for the time and effort it spends, with rework and waiting counted as part of that effort. You raise it by cutting the work that gets redone or sits idle, not by asking engineers to work faster.
Rework and waiting often start before coding, in a requirement that changed after the team built the design or one that took a week to get through review. Common delivery metrics do not count that effort, because they start at the first commit or later. To raise engineering efficiency, you count rework and waiting alongside delivery metrics, find where effort is lost before the first commit, cut that loss without lowering quality, and decide where AI coding tools help or add work.
How Do You Measure Engineering Efficiency?
You measure engineering efficiency with a few metrics that capture different aspects of delivery, counting rework and waiting explicitly. No single number does the job, so you pair the standard delivery metrics with measures of the rework and waiting that happen before coding starts.
Why Can’t One Number Measure Engineering Efficiency?
Nicole Forsgren and colleagues, the authors of the SPACE framework, argue against a single number. They propose measuring productivity across the five dimensions that give SPACE its name: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. The authors write that developer productivity “cannot be reduced to a single dimension (or metric!)” and that only “a constellation of metrics in tension” reveals it.
Martin Fowler went further: he argued that the industry cannot reasonably measure productivity because it cannot measure output. Measure several things at once: use at least three metrics across dimensions, one of them perceptual such as a survey, as the SPACE authors recommend. The same authors warn that activity metrics “should never be used in isolation” to reward or penalize developers.
With any metric, once one number becomes the target, people may improve the number while the outcome it stood for gets worse. In the SPACE authors’ example, story-point ratings lead team members to skip invisible work like onboarding.
Which Delivery Metrics Should You Track?
Track the delivery metrics of the DevOps Research and Assessment (DORA) program for each application or service, and avoid using them to make teams compete. DORA defines five metrics in two groups, throughput and instability:
- Change lead time: A throughput metric measuring time from a commit reaching version control to that change running in production.
- Deployment frequency: A throughput metric counting deployments per period.
- Failed deployment recovery time: A throughput metric measuring time to recover from a deployment that needed immediate intervention.
- Change fail rate: An instability metric measuring the share of deployments needing a rollback or hotfix.
- Deployment rework rate: An instability metric measuring the share of unplanned deployments caused by a production incident.
DORA added deployment rework rate in 2024 to test whether change fail rate had been acting as a proxy for rework. Even that rework measure starts at a deployment. All five metrics measure events from the commit or deployment onward, so none records a requirement that changed before coding started.
How Do You Count Rework and Waiting Before the Commit?
To count rework before the commit, track percent complete and accurate (%C/A), a DORA value stream measure. The measure records how often a step’s input is usable without rework.
For waiting, track flow efficiency. Mik Kersten defines flow efficiency in his Flow Framework (Project to Product) as the share of an item’s total time in the value stream that someone actively works on it. An item that waited longer than the team worked on it scores low, however fast the work itself went.
What Does Engineering Efficiency Count That Productivity and Velocity Don’t?
Engineering efficiency is output against the total effort it cost, so rework and waiting count against it. Productivity is output per unit of time, and velocity is how much a team completes in a sprint.
For example, a team can report rising velocity and falling efficiency in the same quarter. The team counts story points for a feature, then rebuilds it next sprint after a requirement change and counts the rebuild’s points again. Delivery throughput works the same way: it counts a hotfix that undoes last week’s deployment just as it counts a feature.
High performers and low performers split their time between rework and new work differently. In 2016, DORA’s high performers spent 22% less time on unplanned work and rework than low performers. They also spent 29% more time on new work than low performers. Velocity would count both groups’ completed work the same way, while engineering efficiency counts the rework against the output.
When you track efficiency, ask a different question: of the hours the team spent, how many produced something that stayed delivered? Fowler takes the question one step further with outcome over output: the outcome is sales revenue or fewer support calls, and the output is the features produced. Scrum trainer Piyush Rahate argues that velocity’s only use is to help the business forecast.
Where Is Engineering Effort Lost Before the First Commit?
Much of the effort that counts against efficiency is lost in four places: a requirement that changes after work starts, impact analysis done by hand, a review that stalls, and verification repeated for lack of a trace. Repeated verification happens after the first commit, but its cause, a trace that fell out of date, comes before it.
Watch for Requirement Changes After Work Starts
Count the requirement changes approved after design or coding has started, because late requirement change is one of the most cited requirements problems. That survey covered 228 companies, and incomplete or hidden requirements topped its list. Among the five most cited problems, requirements that kept changing (“moving targets”) most often led to project failure: 51% of the companies that cited the problem said so.
Boehm and Basili put avoidable rework at roughly 40 to 50 percent of the effort on software projects in 2001. They also found that a problem caught after delivery often costs far more to fix than one caught during requirements and design, though the gap is much smaller on small, noncritical systems. Part of that cost is likely the work of revisiting the design, code and tests built on the original requirement.
The cost escalation does not hold everywhere. In a study of 171 commercial projects, the time to resolve issues of every type did not rise significantly when they were delayed across phases, in the overwhelming majority of results. Count late changes either way, because the rework they cause is effort against efficiency whether or not its cost rises with delay.
How Much of Your Impact Analysis Is Manual?
Usually all of it, when no tool records which items a change touches: someone re-reads the downstream artifacts by hand after each requirement change. A research team led by Markus Borg describes change impact analysis on safety-critical systems as labor-intensive.
Safety assessment has the same cost: traceability between system design and safety-assessment artifacts is solely manual in current practice. Under those conditions each design change forces the safety engineer to review every Failure Mode and Effects Analysis (FMEA) table or fault tree and adapt the affected parts.
Find Where Reviews Stall
When a review stalls, developers often start a second task and lose time switching back when they return, so record the days each requirement waits between submission and approval. The clearest published numbers on review waits come from code review, the nearest measure for a requirement review.
At Google in 2018, the median time for the whole review process was under four hours. Diff reviews at Meta start to feel slow after about 24 hours. Waiting after approval costs time too. Cutting the wait between a change’s acceptance and its merge could speed up Phabricator code reviews by 29 to 63 percent.
Is Verification Repeated Without a Trace?
Often, yes: without a current trace, you may repeat verification on tests a change did not affect. After a change, a product still needs regression testing on the unmodified portions. How much depends on the change type and on whether safety-related functions or interfaces are involved.
When nobody knows what a change touched, re-running every test is the cautious default. In a case study of two open-source Ada programs, re-test time fell 84% with change impact analysis, because only the impacted tests were re-run instead of the full suite. With a current trace, the team can see which tests a change affected, and it still runs the regression testing that the change itself requires.
How Do You Improve Engineering Efficiency Without Cutting Quality?
You improve engineering efficiency without cutting quality by limiting work in progress, fixing requirement wording before review and keeping the trace current. Before increasing throughput, check whether requirement changes, reviews or repeated verification account for the extra effort.
Limit Work in Progress and Shrink the Batch
DORA found that work in progress (WIP) limits help delivery performance, especially with a visual display and monitoring feedback. On a British Broadcasting Corporation (BBC) Worldwide team, mean feature delivery time fell 37% after the team adopted a set of lean practices, WIP limits among them.
For the limit to help, set it to real capacity including support and meetings, and keep it in place when people are idle. Tighten it if it is easy to meet, because the limit exists to expose problems.
DORA defines small batches as work finishable in a week or less. Working in them shortens the time to feedback and makes problems easier to triage and fix, likely because less has changed between the fault and the feedback.
Fix Requirement Wording Before Review
If a requirement is vaguely worded, the reviewer may have to rewrite it before approving it, so before you send one, check it for measurable, unambiguous wording. A reviewer who has to ask what a vague term means sends the requirement back, and the review starts again.
Review cycle time is the number to track on your own team before and after you change how it manages requirements. IonQ, for example, had been keeping its requirements in Google Sheets before it moved to Jama Connect®, a web-based requirements management and traceability platform for complex, regulated product development.
In 2023, IonQ reported a 25% decrease in review cycle time. IonQ also reported a 20% savings of systems engineers’ time (previously spent on manual processes).
Keep the Trace Current So Change Impact Is Known Before Work Restarts
Trace links make change work on existing software faster: in a controlled experiment, 71 subjects performed real maintenance tasks, half of the tasks with traceability. With traceability they finished on average 24% faster. In the paper-based exercise, they also produced on average 50% more correct solutions.
Teams that build software for regulated products have a second reason to keep the trace current: the safety standards for automotive, aviation and medical software each set rules for handling a change. To meet those rules, some teams update trace links as they work, and others rebuild the links by hand before each release. In automotive, ISO 26262 covers change management as a supporting process (Part 8, 2018 edition). You can read how the 2018 edition applies across a program in Jama Software®’s ISO 26262 guide.
In aviation, an applicant modifying previously approved software conducts a change impact analysis and then the verification it indicates (EASA AMC 20-115D). DO-178C identifies that analysis (Section 12.1). For medical device software, IEC 62304 requires the manufacturer to verify each change, including any verification the change invalidated (Clause 8.2.3). When the trace is out of date, a team has no quick way to tell which verification a change invalidated, so it usually re-runs more than the change requires.
How Does AI Change Engineering Efficiency?
AI coding tools raise task output in field experiments. In the ClarifyCodeBench benchmark, the code large language models (LLMs) generate gets worse when the specification is ambiguous.
How Much AI Helps
How much AI helps depends on who uses it and on what kind of work. In field experiments, 4,867 developers at Microsoft, Accenture and a Fortune 100 company used an AI coding assistant. The experiments found a 26.08% increase in completed tasks, a count of finished tasks that does not measure their quality. Less experienced developers adopted the coding assistant more often and gained more.
A contrasting result came from a 2025 randomized trial by Model Evaluation and Threat Research (METR), involving 16 experienced developers working on familiar projects. With AI allowed, the developers were slowed by 19%. They had expected AI to speed them up by 24%.
In a later randomized trial of open-source developers using late-2025 agents, METR “found small (~4-20%) productivity benefits.” METR expects that figure to understate the effect, because some developers who did not want to work without AI chose not to take part.
Where AI Adds Risk
AI can save coding time and still add audit work, a trade-off DORA calls a verification tax. In 2025, DORA found that higher AI adoption went with higher delivery throughput and also with higher delivery instability. Of the developers it surveyed, 30% reported little or no trust in AI-generated code.
In a Meta trial of AI-suggested fixes to review comments, review time rose over 5% because reviewers were checking the AI patches. Once only authors saw the patches, the slowdown disappeared.
In ClarifyCodeBench, which compares ambiguous and complete requirements, pass@1 (the share of problems solved on the first attempt) was lower under ambiguous requirements for every model tested, by 7.8 to 19.8 points even after the benchmark’s clarification round. When specific details are missing, the models make implicit assumptions that diverge from the intended behavior. The HumanEvalComm benchmark made problem descriptions ambiguous, inconsistent or incomplete. In more than 60% of responses, code LLMs generated code without asking a clarifying question.
What Keeps AI Output Tied to the Specification
To keep AI output matching the specification, have a person approve what the agent runs and give the agent the current approved version to work from. By default, GitHub Actions workflows do not run on a pull request from GitHub’s coding agent until a person approves them to run. When you review the agent’s pull request, treat any change that weakens continuous integration (CI) as a blocker. Agent tooling follows the same principle: the Model Context Protocol (MCP) specification expects a human to be able to deny tool invocations.
Approval alone does not establish whether an agent used the current specification. A requirement pasted into a general-purpose chat tool usually lacks the original’s links, permissions and version history. Without those records, the agent may be unable to distinguish the approved version from an outdated copy.
When you change direction, revise the approved specification first and generate the new plan from it, so the agent works from the version your team approved. Your team keeps the approved specification current by checking each requirement’s wording and maintaining its trace links.
How Jama Connect Supports Engineering Efficiency
Late requirement changes, manual impact analysis, stalled reviews and repeated verification each have a matching capability in Jama Connect. When a linked requirement changes, Jama Connect marks the test cases and risk items built on it as suspect, and impact analysis shows the scope of the change before work restarts, which gives the team a starting point for the retest set. Jama Connect has built-in test management in Test Center: you write test plans, execute test runs and log defects from failed test steps in the same tool as the requirements they verify, with no separate test tool to license or integrate. Jama Connect Review Center tracks review progress and approvals so you can see which reviews are still waiting for approval. Together, these make up the linked, change-aware approach Jama Software calls Live Traceability™.
AI agents can read a project’s requirements and trace links through the separate MCP Server add-on, one of the AI capabilities in Jama Connect, on Cloud and Self-Hosted deployments, under Jama Connect’s permissions and audit requirements. Before you send a requirement for review, Jama Intelligence analyzes its wording against 30 of the 40 International Council on Systems Engineering (INCOSE) rules and the six Easy Approach to Requirements Syntax (EARS) patterns, and you accept, edit or reject each suggested rewrite. Jama Intelligence is an add-on for Jama Connect Cloud.
Building Engineering Efficiency Into the Requirements Layer
Start measuring effort at requirement approval, before the first commit. Track the rework hours a requirement change causes and the days it waits for review alongside DORA’s five metrics. Before scaling up code generation, measure upstream waiting and any review time added by AI-written changes. Count a speedup as an efficiency gain only if the saved effort exceeds the added review and rework.
Choose one real requirement change and use its links and review record to locate the rework hours and waiting days you are counting. To check that workflow with the Jama Software team, you can see it in action.
Frequently Asked Questions About Engineering Efficiency
Is flow efficiency the same as engineering efficiency?
No. Flow efficiency compares the time someone actively works on an item with the item’s total elapsed time, so it records waiting and leaves rework uncounted. A change that moves through quickly and comes back as a hotfix scores well on flow efficiency, while engineering efficiency counts the hotfix as effort against the same output.
How do you start counting rework that traces to requirements?
You can tag each reopened ticket, rebuild or hotfix with the requirement and the change that triggered it, then sum the hours spent on those tagged items each quarter. Alongside those hours, record review waiting days from submission to approval, and use the first full quarter as your baseline.
Which rework statistics should you stop quoting?
Stop quoting the widely reproduced “Systems Sciences Institute” cost-escalation chart. Laurent Bossavit, a technical advisor at the software consultancy CodeWorks, traced the Institute to an internal training program with no supporting data.
Does Automotive SPICE require re-verification after a requirement change?
Yes, through its verification processes: in version 4.0 of Automotive SPICE (Software Process Improvement and Capability Determination), teams select system verification measures using criteria that include regression verification, for example after requirements change (SYS.5). Automotive SPICE is a process assessment model, not a safety standard, and teams apply the same criteria to software verification (SWE.6).
Each change request also needs bidirectional traceability to the work products it affects, plus confirmation that the change was implemented (SUP.10). To set up that traceability in practice, work through Jama Software’s guide to engineering change management.
