Acceptance criteria
Observable conditions that describe when a required behaviour or outcome can be considered acceptable.
Book / glossary
Engineering
Excellence
A practical glossary of concepts, practices and patterns related to building good software.
Book in progressEngineering Excellence
Glossary
Search by name, abbreviation, definition or tags. Every term has its own link.
ADR
Agile
A set of principles and ways of working based on short feedback loops, collaboration and adapting to new knowledge; not one specific process or framework.
AI
Alert
A signal that a defined condition requires attention or action. A useful alert should lead to a concrete response, not just more notifications.
Anti-pattern
A recurring way of working that appears reasonable or professional but repeatedly leads to undesirable outcomes.
API
API contract
An agreed definition of an API’s operations, data formats, behaviour and compatibility expectations between producer and consumer.
Application Programming Interface
API
An agreed way for systems or components to communicate, defining available operations, inputs, outputs and usage rules.
Architecture Decision Record
ADR
A short document describing a significant architectural decision, its context, considered options and consequences.
Artifact
An identifiable output of the software build process, such as an application package, container image or binary.
Artificial Intelligence
AI
A broad term for systems that perform tasks associated with human reasoning, content generation, analysis or decision support.
Assumption
Information accepted provisionally without full confirmation; assumptions with high impact should be visible and verified when necessary.
Automated test
A test executed by a tool without a person manually performing the scenario, enabling fast and repeatable feedback.
Backend
The server-side part of a system responsible for logic, data access, integrations and services not directly visible to users.
Backlog
An ordered list of needs, features, defects or other work that may be considered or delivered; it should not become an archive of undecided ideas.
Backward compatibility
The ability of a newer version to remain compatible with clients, data or interfaces designed for an earlier version.
Benchmark
A result, practice or system used as a reference point for comparison; it is not necessarily a standard to copy directly.
Blocker / blockage
A state in which work cannot meaningfully progress until a specific obstacle, decision or dependency is resolved.
Blue/green deployment
A deployment strategy that keeps old and new environments running in parallel and switches traffic between them.
Bottleneck
A point in the system that constrains overall flow, such as a queue to one person, environment or review step.
Branch
A separate line of development in version control that allows changes to be made without immediately modifying the main branch.
Bug / defect
A mismatch between actual and expected system behaviour, caused by code, configuration, data, integration or another part of the solution.
Build & Verify
The part of the change journey in which a solution is built, integrated and verified so it can be trusted before deployment.
Business-to-Business
B2B
A model of products, services or relationships aimed at other organisations rather than directly at consumers.
B2B
See: Business-to-Business
CAB
Canary deployment
A gradual deployment of a new version to a small portion of traffic or users so its real behaviour can be observed before wider exposure.
CD
See: Continuous Delivery
Change
The book’s main “character”: any intended modification of the current state, such as a new feature, defect fix, behaviour change, migration, configuration change or removal.
Change Advisory Board
CAB
A group that supports assessment and coordination of changes, especially in IT service management approaches.
Change Fail Rate
A DORA metric showing what proportion of production changes cause an undesirable outcome that requires remediation, rollback or intervention.
Change freeze
A temporary restriction or ban on production changes, usually during periods of increased business or operational risk.
Change Lead Time
The time from committing a code change until it is successfully running in production.
Change Management
The practice of assessing, planning and controlling changes in an IT service environment to introduce technical and operational changes safely.
CI
Code review
A review of code changes by another person or automated mechanism to detect issues, share knowledge and maintain standards.
Commitment
A deliberate declaration of responsibility for a defined outcome under agreed conditions, distinct from an estimate, forecast or desired date.
Common minimum / minimum standard
The smallest shared set of principles or conditions worth preserving regardless of the team’s detailed way of working.
Compliance
Conformance with applicable legal, regulatory, contractual, standards-based or internal policy requirements.
Confidence level
An explicit indication of how trustworthy a forecast or assumption is given current knowledge and uncertainty.
Confluence
Atlassian software for creating and sharing documentation, knowledge pages and team materials.
Container
A lightweight isolated runtime package containing an application and the dependencies needed to run it.
Containerization
Packaging and running applications in containers to improve consistency, isolation and portability across environments.
Context switching
The cognitive cost of moving attention between different tasks or problems, often increasing delay and reducing focus.
Continuous Delivery
An approach in which software is continuously kept in a state that allows a safe and repeatable release.
Continuous Deployment
A model in which successfully verified changes can automatically reach production without a separate manual deployment decision.
Continuous Integration
CI
The practice of frequently integrating small changes with automated verification that exposes problems quickly.
Continuous Integration / Continuous Delivery / Continuous Deployment
CI/CD
Practices and automation used to build, test, prepare and deliver software changes; CD may mean Continuous Delivery or Continuous Deployment.
Contract
An agreed interface or set of expectations defining how two parties, components or systems interact.
Contract test
A test that verifies a producer and consumer conform to an agreed interface contract, such as an API contract.
Cycle Time
The elapsed time from an agreed start of active work to its completion; measurement boundaries must be defined consistently.
Dashboard
A set of charts and indicators that shows the state of a system, product or work and should support specific questions and decisions.
Deadline / hard deadline
A date after which a real legal, contractual, market or operational consequence occurs; it is different from a desired date.
Define / Ready
An industry label for the preparation stage in which scope and working conditions are clarified enough for responsible execution to begin.
Definition of Done
DoD
A shared, unambiguous set of conditions defining when a piece of work can be considered genuinely complete.
Definition of Ready
DoR
A team agreement describing the minimum conditions under which work is sufficiently understood, small and safe to start; it is not a formal Scrum Guide element.
Demand
A general term for an impulse to start work, such as a business need, user problem, risk, legal requirement or technical debt.
Dependency
A situation in which one outcome depends on a decision, data, system, supplier or result provided by someone else.
Deployment Frequency
How often an organisation successfully deploys changes to the production environment.
Deployment Rework Rate
A delivery metric showing what proportion of deployments require subsequent corrective or remedial work.
Deploy / deployment
Placing a new artefact or configuration into an environment, usually production; it does not necessarily mean the feature is available to users.
Developer / software developer
A person who designs, writes, reviews and maintains software code and contributes to technical decisions.
DevOps
An approach that connects software development, automation, deployment and operations into one flow of responsibility and feedback.
DevOps Research and Assessment
DORA
A research programme and body of practices and metrics used to assess an organisation’s technical software delivery capabilities.
DevSecOps
An approach in which security is integrated into design, build, testing, deployment and operations instead of being a final gate.
Directly Responsible Individual
DRI
One named person responsible for driving an issue to an outcome or decision, without implying they do all the work or own every decision right.
Discovery
Work performed to understand the problem, users, solution options, risks and unknowns before making further investment decisions.
Discover / Validate
An industry label for discovery work that checks the problem, hypotheses, feasibility and critical unknowns before larger investment.
Distributed trace / trace
A record of one request or operation as it travels through multiple services and components in a distributed system.
Docker
A widely used platform and toolset for building, running and distributing containers.
DoD
See: Definition of Done
DoR
See: Definition of Ready
DRI
Endpoint
A specific address or operation exposed by an API where a system accepts defined requests.
End-to-end
E2E
A term covering an entire flow across multiple components or systems; in testing, it means verifying a complete user or business scenario.
End-to-end test
A test that verifies a complete flow across multiple layers or systems from a user or business-process perspective.
Engineering Excellence
An organisation's ability to deliver value systematically through sound technical practices, deliberate decisions and continuous learning.
Error budget
The acceptable margin by which a reliability target may be missed, derived from an SLO and used to balance delivery speed with stability.
Escalation
Raising an issue or decision to a level with the authority, resources or ability to remove the obstacle.
Estimate
An approximate assessment of size, complexity or effort; it is not automatically a date or commitment.
Expand / Migrate / Contract
A safe-change pattern in which a new compatible structure is added first, usage or data is migrated, and the old structure is removed last.
E2E
See: End-to-end
Fact
Information supported by a credible source or observation; in discovery it is distinguished from assumptions and hypotheses.
Failed Deployment Recovery Time
A DORA metric measuring how quickly normal service is restored after a failed production change.
Fast track / lightweight path
A lightweight path for small, well-understood, low-risk changes that reduces ceremony without removing necessary thinking.
Feature flag / feature toggle
A mechanism that separates deploying code from exposing a feature, allowing functionality to be enabled, disabled or limited without redeployment.
Feature toggle
Feedback
Information about the result of an action or change that can be used to adjust the next decision or behaviour.
Finish before start
A flow principle that encourages helping finish work already in progress before opening additional work.
Flaky test
A test that can pass or fail without a relevant code change, reducing trust in automated checks and encouraging teams to ignore failures.
Flow
The movement of work, information, decisions and value through the delivery system from need to outcome.
Forecast
A current prediction of a future result, date or amount of completed work, based on available evidence and assumptions.
Framework
A structured set of concepts, roles or practices that provides a way of organising work without necessarily prescribing every detail.
Frontend
The user-facing part of an application responsible for presenting information and handling user interaction.
Gherkin
A text format for describing system behaviour, commonly using Given, When and Then statements in behaviour-driven development.
Git
A distributed version control system widely used to manage source code and change history.
GitLab
A platform for source code management, CI/CD, collaboration and other software delivery activities.
Governance
The system of oversight, decision rights and information flow used to ensure important issues become visible and are decided by the right people.
Guardrail
A pre-agreed condition, limit or threshold intended to stop risk from increasing or trigger action when a safe range is exceeded.
Handbook
A documented guide to organisational practices, rules, knowledge or ways of working, often maintained as a living reference.
Handoff
A transfer of work or responsibility from one person, role or team to another, often creating waiting time and context loss.
Hard dependency
A dependency without which a specific part of the work cannot start or finish or the required outcome cannot be achieved.
HTTP status codes
Standard three-digit codes used by HTTP to describe the outcome of a request, such as success, redirection, client error or server error.
HTTP 200 OK
An HTTP status code indicating that a request was processed successfully and a response is being returned.
HTTP 204 No Content
An HTTP status code indicating successful processing with no response body.
Hypertext Transfer Protocol
The application protocol commonly used for communication on the web and by many APIs.
Hypothesis
A testable statement linking a proposed change to an expected outcome.
Incident
An unplanned event that disrupts or degrades a service and requires restoration, diagnosis or mitigation.
Integration test
A test that verifies the interaction of at least two components or systems.
Issue / problem
A condition, obstacle or undesirable outcome that requires understanding or action; in software work it should be separated from the first proposed solution.
Jira
Atlassian software commonly used for issue tracking, work management and software delivery workflows.
Kanban
A method for managing flow by visualising work, limiting work in progress and improving the system based on observed behaviour.
Key Performance Indicator
KPI
A key performance indicator used to track performance against an important objective.
KPI
Kubernetes
An open-source platform for orchestrating containerised applications, including deployment, scaling and service management.
Lagging indicator
A metric that reports an outcome after it has occurred, such as incident rate, recovery time or business result.
Launch
The moment or decision when a feature becomes available to its intended users; it may happen after technical deployment and release.
Leading indicator
A metric that may provide an earlier signal of future outcomes, such as work age, queue size or a growing backlog of failed checks.
Lead Time
The elapsed time from an agreed entry point in the delivery system to delivery of the result.
Log
A recorded event or message produced by a system to support observation, diagnosis, audit or analysis.
Mainline
Main branch / mainline
The primary branch or mainline of a repository into which completed changes are integrated.
Manual test
A test performed manually by a person, useful where exploration, human judgement or one-off verification is needed.
Mean / average
The arithmetic mean: the sum of values divided by their count; it can be distorted by extreme observations.
Median / 50th percentile
The middle value in an ordered dataset, equivalent to the 50th percentile and less sensitive to extreme values than the mean.
Merge request
A request to review and merge a set of code changes into another branch; called a pull request on some platforms.
Microsoft SharePoint
A Microsoft platform for sharing documents, pages and organisational information.
Migration
A controlled movement of data, functionality, users or infrastructure from one state, system or version to another.
Mock
A controlled substitute for a dependency that can return defined responses and often verify expected interactions.
Monitoring
The ongoing observation of known system signals and conditions to detect failures, degradation or threshold breaches.
NFR
Non-functional requirements (NFRs)
Requirements describing qualities other than functional behaviour, such as performance, security, availability, observability, compliance or compatibility.
N / N+1 compatibility
A compatibility model in which adjacent versions can coexist, making gradual rollout and migration safer.
Observability
The ability to understand a system's internal state from the signals it produces, such as logs, metrics and traces.
Onboarding
The process of introducing a new person to an organisation, team, product or system so they can work effectively.
OpenTelemetry
An open standard and ecosystem for generating, collecting and exporting telemetry such as traces, metrics and logs.
Operate & Learn
The part of the change journey in which the solution operates in production and real data is used to learn and make further decisions.
Operations / maintenance
Work required to keep a system operating after deployment, including incident response, monitoring, diagnosis, updates and reliability improvement.
Percentile
A value below which a specified percentage of observations in a dataset falls.
Performance test
A test that measures behaviour under defined load, such as latency, throughput or resource utilisation.
Pipeline
An automated sequence of steps used to build, verify, package or deploy software.
Plan
A current intention describing what is expected to be done based on the knowledge available now.
Plan & Forecast
The stage in which priorities, capacity, estimates, dependencies and uncertainty are combined into a realistic plan and forecast.
PoC
See: Proof of Concept
Post-mortem
A structured analysis after an incident or significant event to understand contributing conditions and improve the system.
Priority
A relative ordering that shows which item should take precedence over another when resources or capacity are limited.
Probabilistic forecast
A forecast expressed as a probability or percentile rather than a single deterministic date, making uncertainty visible.
Production
The live environment in which real users, business processes or dependent systems use the software.
Progressive delivery
A way of releasing changes gradually to controlled groups or portions of traffic while observing results and limiting risk.
Proof of Concept
PoC
A minimal proof used to check whether a critical concept is technically feasible; it is not automatically production-ready software.
Prototype
A simplified representation of a proposed solution used to learn about behaviour, usability or assumptions before building the full product.
Pull request
See: Merge request
QA
See: Quality Assurance
QE
See: Quality Engineering
Quality Assurance
QA
Activities aimed at assuring and improving confidence in product quality; in many organisations the abbreviation is also used for testing roles or teams.
Quality Engineering
QE
An engineering approach to quality that builds testability, automation, feedback and quality controls into the whole delivery system.
Quality gate
An automated or manual condition that can stop a change from progressing when a required quality signal is not met.
Ready
A label indicating that work appears sufficiently understood and prepared to start; the status itself is not proof of real readiness.
Refactoring
A change to the internal structure of code without intentionally changing its external behaviour, usually to improve maintainability or evolvability.
Refinement / backlog refinement
The ongoing work of clarifying and agreeing information needed to start implementation sensibly; it does not have to be a recurring meeting.
Release
The decision or moment when a deployed version is considered ready for use in an intended scope; distinct from deploy and launch.
Release notes
A concise description of changes included in a release for users, operations teams or other stakeholders.
Reliability
The ability of a system or service to perform its intended function consistently over time and under expected operating conditions.
Reliability test
A test that checks system behaviour during failures, overload, dependency loss or other conditions affecting continuity of service.
Responsible, Accountable, Consulted, Informed
RACI
A responsibility model identifying who is Responsible, Accountable, Consulted and Informed for a task or decision.
Risk
An uncertain future event or condition that may affect outcome, time, cost, security or quality and should include a possible impact and response.
Roadmap
A high-level view of direction, sequencing, important dependencies and time horizons; it should not be treated as a fixed detailed schedule.
Rollback
Restoring a previous state after a problematic change; it may not be possible or sufficient for irreversible data migrations.
Roll-forward
Restoring service by preparing and deploying a corrective change instead of reverting the whole previous change.
Runbook
A concise operational procedure for handling a known problem or operation, written for use under time pressure.
Scrum
A lightweight framework for developing complex products using Sprints, defined accountabilities, events and artefacts.
Scrum Guide
The canonical document describing Scrum’s accountabilities, events, artefacts and rules.
SDLC
Secure Software Development Life Cycle
Secure SDLC
An SDLC in which security is integrated from the beginning through requirements, design, controls, testing and vulnerability response.
Security
Protection of systems, data and users against unauthorised access, misuse, loss of integrity and other threats.
Security test
A test that checks a solution’s resistance to threats, misuse, incorrect permissions or other security weaknesses.
Service
A distinct system capability that provides a function to a user or another system and may have its own reliability objectives and owning team.
Service Level Agreement
SLA
A formal agreement between parties defining an expected service level and often consequences if it is not met; distinct from an internal SLO.
Service Level Indicator
SLI
A measurable indicator of service quality, such as availability, latency or the percentage of successful operations.
Service Level Objective
SLO
A target level for a selected SLI over a defined period, intended to reflect service quality that matters to users and influence decisions.
Shift Left
Moving quality, security and feedback activities to earlier stages of the software delivery process.
Site Reliability Engineering
SRE
An approach that applies software engineering to reliable service operation, automation, SLI/SLO practices and reliability risk management.
Sizing
The practice of assessing the relative size or complexity of work, often using story points, T-shirt sizes or another scale.
SLA
SLI
SLO
Small batch
A deliberately small, coherent portion of work that can be completed and verified quickly, reducing risk and shortening feedback loops.
Software
Programs, services, libraries and other computer-executed components together with their logic and configuration.
Software Delivery
The complete system from a need or problem to a working production solution and feedback about its effect, not just coding or deployment.
Software Development Life Cycle
SDLC
The complete lifecycle of activities involved in creating, evolving, deploying and maintaining software.
Soft dependency
A dependency whose absence makes work harder or reduces value but does not prevent further work or delivery of a minimal scope.
Source of truth / single source of truth
A place recognised as the current and reliable source for a particular piece of information so people do not reconstruct state from conflicting documents.
Spike
A time-boxed technical investigation used to answer a specific question or reduce a significant unknown; its output is knowledge, not a finished feature.
Sprint
A fixed-length Scrum timebox in which the team works toward a Sprint Goal and creates a valuable product increment.
Sprint Goal
A single coherent objective that gives direction to work in a Sprint and is more important than treating the selected task list as a fixed contract.
SRE
Story point
A relative unit used by some teams to estimate size, complexity or uncertainty; it is not a unit of time or a productivity measure.
Stub
A simple substitute for a dependency that returns predefined responses and usually does not verify how it was called.
Target date / expected date
A date by which someone would like a result to be available; unlike a hard deadline, it may not have a concrete consequence if missed.
Team capacity / availability
The team’s real ability to take on work after accounting for work in progress, operations, absences, unplanned work and skill constraints.
Technical debt
A future cost caused by earlier technical decisions that accelerated delivery at the expense of the solution's future changeability.
Telemetry
Data emitted by a system and collected to observe its behaviour, including metrics, logs, traces and events.
Testability
A property describing how easily and reliably a solution’s behaviour can be verified; good testability shortens feedback time.
Throughput
The number of work items or outcomes completed by a system in a defined period.
Triage
A lightweight assessment of a new need or problem used to decide what should happen next, such as discover, defer, reject or fast-track it.
Unit test
A test of a small unit of code performed in isolation from most external dependencies.
Unknown
A question or piece of information that is not yet known and may need to be reduced before a decision can be made responsibly.
Unplanned work
Work that was not part of the original plan, such as incidents, urgent support, unexpected defects or mandatory interventions.
User Experience
UX
The overall experience a user has when interacting with a product or service, including clarity, ease, effectiveness and perceived quality.
UX
See: User Experience
Velocity
A team-level measure of work completed across Sprints, usually in story points; useful for local planning but not for comparing productivity.
Visibility
The ability for relevant people to quickly see the real state of work, risks, dependencies, forecasts and decisions needed.
Waterfall
A sequential way of organising work in which phases follow one another with limited return to earlier stages.
WIP
See: Work in Progress
Work in Progress
WIP
The amount of work started but not yet finished; excessive WIP increases queues, context switching and cycle time.
Work item age / age of work
How long an active work item has been in the system since it started; rising age can reveal stuck work before a deadline is missed.
50th percentile (P50)
P50
The 50th percentile: half of observed cases are at or below this value and half are above it.
85th percentile (P85)
P85
The 85th percentile: 85 percent of observed cases are at or below this value.
90th percentile (P90)
P90
The 90th percentile: 90 percent of observed cases are at or below this value.
95th percentile (P95)
P95
The 95th percentile: 95 percent of observed cases are at or below this value.
99th percentile (P99)
P99
The 99th percentile: 99 percent of observed cases are at or below this value.
No results
Try a different phrase or clear the selected filters.
Engineering Excellence
Playbooks
Book in progress
Practical guides that turn ideas from the book into concrete team actions, decisions and routines.