Engineering Delivery
Glossary
Plain-language definitions of the words used in DORA research and in our delivery guides. Each entry is short and links to the guide that explains it in full. If you are completely new, start with What is DORA?.
A
AI as an amplifier
DORA's main finding about AI in software teams: AI magnifies what is already there, the strengths of teams that work well and the problems of teams that struggle. Buying AI tools alone does not fix a slow or unstable delivery process. See AI and software delivery.
AI-assisted change
A change that an AI tool helped write. The Engineering Delivery app counts a change as AI assisted when its commits carry an AI co-author tag, never by reading the code. See AI-assisted changes.
B
Batch size
How much work goes into one change or one release. Small batches are quicker to review, easier to test and simpler to undo, which is why DORA treats working in small batches as a core capability. See change size.
Burnout
DORA defines burnout as "physical, mental, or emotional exhaustion caused by overwork or stress". DORA's research puts the fix in how work is organised, not in the people. See Well-being and burnout.
C
Capability (DORA)
A practice or condition that DORA's research links to better delivery, such as continuous integration, test automation, working in small batches or a healthy team culture. Capabilities are what you improve; the DORA metrics show whether it worked. DORA lists them at dora.dev/capabilities. See Improving software delivery.
Change
Any edit to the software: a new feature, a bug fix, a configuration tweak. On a code host a change usually arrives as a pull request.
Change approval board
A group, often outside the team, that must approve changes before they go live. DORA found that heavyweight external approval slows delivery and found no evidence that it lowers change fail rates. See Improving software delivery.
Change fail rate
The share of deployments that need immediate intervention, such as a rollback or hotfix, after going live. Also called change failure rate. One of the five DORA metrics. See Change fail rate.
Change lead time
How long a change takes to go from committed to version control to running in production. Also called lead time for changes. One of the five DORA metrics. See Change lead time.
Cluster analysis
A statistical method that sorts answers into groups that are similar inside and different from each other. DORA uses it to find its performance levels and team profiles, rather than deciding the groups in advance. See DORA performance levels.
Code review
When someone other than the author reads a change before it is merged, to catch mistakes and share knowledge. Waiting for a review is often the biggest wait in delivering a change. See Code review speed and size.
Cognitive load
How much mental effort it takes to understand the code, find answers and work with the tools. One of the three dimensions of developer experience. See Developer experience (DevEx).
Commit
Saving a change into version control. A commit records what changed, who changed it and when. Change lead time starts at the commit.
Continuous delivery
Keeping software in a state where any change can be released to users safely and quickly, at any time, usually through an automated deployment pipeline. A DORA core capability.
Continuous integration
Merging everyone's changes into a shared main branch often, at least daily, with automated builds and tests checking each one. It catches conflicts and bugs early, while they are small. A DORA core capability.
Cycle time
How long a piece of work takes from when someone starts it to when it is done. People use the term loosely, so always check where the clock starts and stops. See Flow of work.
D
Deployment
The moment a change is put live so real users get it. Also called a release or shipping. What counts as a deployment should be agreed and kept stable, for example a production deployment run by the pipeline.
Deployment frequency
How often a team deploys changes to production. One of the five DORA metrics. See Deployment frequency.
Deployment pipeline
The automated steps that take a change from version control to production: building it, testing it and deploying it. A good pipeline makes deployments routine and boring.
Deployment rework rate
The share of deployments that were not planned but happened because of an incident in production. Added in 2024 as the fifth DORA metric. See Deployment rework rate.
DevEx
Short for developer experience: how people experience their working day. The DevEx framework looks at three things, feedback loops, cognitive load and flow state. See Developer experience (DevEx).
DORA
DevOps Research and Assessment, a research programme that has studied software delivery for more than a decade and is now part of Google Cloud. Not to be confused with the EU's Digital Operational Resilience Act. See What is DORA?.
E
Elite performer
The name DORA gave the best-performing group in its survey in a given year. In 2024, elite performers reported change lead time under a day, deploying on demand, a 5% change fail rate and recovery in under an hour. It is a label from the data, not a target. See DORA performance levels.
F
Failed deployment recovery time
How long it takes to recover from a deployment that fails and needs immediate intervention. It replaced MTTR as a DORA metric. See Failed deployment recovery time.
Failure demand
Work a team has to do because something went wrong earlier, such as fixing bugs, instead of work that adds something new. A high share of bug fixing means less capacity for building. See where the work went.
Feature flag
A switch in the code that turns a feature on or off without deploying again. It lets a team deploy unfinished work safely, hidden from users, and turn off a feature that misbehaves.
Flow state
Being able to focus on work without being pulled away. One of the three dimensions of developer experience. DORA's 2024 report measures flow as how much focus a person tends to achieve during development tasks. See focus time.
Friction
Anything that gets in the way of doing the work: slow tools, unclear processes, waiting on others. DORA's 2025 research treats lower friction as a good outcome. See Developer experience (DevEx).
G
Goodhart's law
The observation that when a measure becomes a target, it stops being a good measure, because people find ways to move the number without improving the thing it was meant to show. It is why DORA warns against turning its metrics into goals. See The five DORA metrics.
H
Hotfix
An urgent fix deployed to repair a problem in production, outside the normal flow of planned work. A deployment that needs a hotfix counts towards change fail rate.
I
Incident
An unplanned problem in production that affects users, such as an outage or a serious bug. Teams usually track incidents in a tool such as PagerDuty or Jira Service Management.
Instability
DORA's name for the group of metrics that show how often deployments cause trouble: change fail rate and deployment rework rate. Lower is better. See Throughput and instability.
J
J-curve
The pattern where performance dips for a while after a team adopts something new, such as AI tools, before rising above where it started. DORA calls the dip the tuition cost of the change. See AI and software delivery.
L
Lead time
How long something takes from start to finish. In DORA, it usually means change lead time: from commit to production. Some teams also measure from when work on a ticket starts. See Change lead time and ticket to customer.
M
Median
The middle value when you line numbers up from smallest to largest: half are below it and half above. The Engineering Delivery app uses medians for times such as change lead time, because a single change that sat for a month would drag an average up and hide what usually happens.
Merge
Adding a reviewed change into the main branch of the code, where it becomes part of what will be deployed.
MTTR
Mean time to recovery, the average time to restore service after an outage. It was one of DORA's original four key metrics and has been replaced by failed deployment recovery time. See Failed deployment recovery time.
P
Production
The live system that real users use, as opposed to a test or staging copy.
Pull request
A proposed change on a code host such as GitHub, where others can review and discuss it before it is merged. GitLab calls it a merge request.
R
Review coverage
The share of merged changes that were reviewed before they were merged. See review coverage.
Rework
Work done again because it was not right the first time: fixing a release, reopening a ticket, redoing a feature. See Deployment rework rate and reopened tickets.
Rollback
Undoing a deployment by going back to the previous working version. A deployment that has to be rolled back counts towards change fail rate. Making rollback a single step shortens recovery time.
S
Service
One deployable part of a system, such as a payments service or a booking website, usually owned by one team. DORA advises applying its metrics to one application or service at a time. See change fail rate by service.
Small batches
Splitting work into small changes that each can be finished, reviewed and deployed on their own, ideally within hours or a couple of days. A DORA core capability, and one of the seven AI capabilities. See Improving software delivery.
T
Team profile
One of seven groups of teams DORA found in its 2025 research by looking at delivery, product results and well-being together, from "foundational challenges" to "harmonious high-achievers". See Team profiles.
Throughput
DORA's name for the group of metrics that show how quickly changes flow to users: change lead time, deployment frequency and failed deployment recovery time. Higher throughput is better. See Throughput and instability.
Time to first review
How long a change waits from being opened until someone first reviews it. See time to first review.
Time to merge
How long a change takes from being opened until it is merged. See time to merge.
Trunk-based development
Working in small changes merged into one shared main branch (the trunk) often, instead of keeping long-lived separate branches. It goes hand in hand with continuous integration.
V
Value stream
All the steps a piece of work goes through from idea to the customer, including the waits between them.
Value stream mapping
A team exercise to draw the value stream, measure how long each step and each wait takes, and find the biggest delay. DORA recommends it as a way to find what is holding delivery back. See find your biggest constraint.
Verification tax
The extra time spent checking AI-generated work, through reviews and tests, because AI produces more code and its output cannot simply be trusted. DORA's ROI report names it as one of the hidden costs of adopting AI. See AI and software delivery.
Version control
A system that keeps the full history of every change to the code, who made it and when, usually Git. Change lead time starts when a change is committed here.
W
Well-being
DORA describes well-being as a reflection of people's happiness and job satisfaction. It is one of the outcomes DORA's research cares about, next to organisational performance. See Well-being and burnout.
Work in progress (WIP)
The work a team has started but not finished. The more work is in progress at once, the longer each item takes, so limiting it is a DORA capability. See work in progress.
Working agreement
A rule a team agrees about how it works, such as "every change gets a first review within a working day" or "keep changes under 400 lines". It turns a retrospective conversation into something the team can check. See working agreements.