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.
Action item
A concrete next step resulting from a meeting, retrospective, analysis or experiment. It should have an owner and a date or method for checking the outcome.
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.
Agile Manifesto
The Manifesto for Agile Software Development and its underlying principles. In the book it is a reference for collaboration, simplicity, fast feedback, adaptation and sustainable pace rather than a ready-made process.
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
An agreed way for systems or components to communicate, defining available operations, inputs, outputs and usage rules.
Architecture Decision Record
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
A broad term for systems that perform tasks associated with human reasoning, content generation, analysis or decision support.
Assessment
A structured look at how a team actually works. It is not a framework-compliance exam but an analysis of real work, queues, decisions, meetings, WIP and exceptions.
Assumption
Information accepted provisionally without full confirmation; assumptions with high impact should be visible and verified when necessary.
Asynchronous communication
Communication that does not require all participants to be present at the same time. It works well for status, context, comments and documented decisions when information has a reliable source of truth.
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.
Baseline
A picture of the state before a change, used to compare the later effect. It may include data, distributions, observations and qualitative signals.
Batch / Batch size
A portion of work moved through the system as one unit. Smaller batches usually shorten feedback time, reduce the impact of errors and make direction changes easier.
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.
Buffer
Deliberately reserved capacity for variability, unplanned work or uncertainty. It is not idle time but protection against assuming reality will follow the plan exactly.
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
A model of products, services or relationships aimed at other organisations rather than directly at consumers.
B2B
See: Business-to-Business
CAB
Cadence
An agreed rhythm of recurring planning, synchronisation, feedback and learning loops. It should follow system needs rather than a habitual ceremony calendar.
Calendar load
The amount and distribution of meetings across the workday. What matters is not only total time but also fragmentation and its effect on focused work.
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.
Carry-over
Work started in one period and not finished before the next begins. It continues to consume attention and capacity even when a new Sprint or planning period has started.
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
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 flow
A way of working in which items are pulled and completed as capacity becomes available, without having to group work into Sprints. Regular planning and review cadences may still be used.
Continuous improvement
A team's ongoing ability to observe its work system, form hypotheses, experiment and verify effects. It is not synonymous with retrospectives alone or with continuously adding practices.
Continuous Integration
The practice of frequently integrating small changes with automated verification that exposes problems quickly.
Continuous Integration / Continuous Delivery / Continuous Deployment
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.
Cross-functional
A way of collaborating in which the necessary skills contribute to a shared outcome instead of acting as sequential silos. It does not mean every person must be able to do everything.
Cumulative Flow Diagram
A chart showing how many items are in successive workflow states over time. It helps reveal growing WIP, queues and changes in system throughput.
Cycle Time
The elapsed time from an agreed start of active work to its completion; measurement boundaries must be defined consistently.
DACI
A decision model in which the Driver leads the issue, the Approver has final decision authority, Contributors provide input and Informed parties receive the outcome. It should reduce ambiguity rather than become mandatory for every decision.
Daily / Daily Flow Review
A short synchronisation used to adapt today's plan and flow. It is not a manager status meeting; its purpose is to help finish work already in progress and remove blockers.
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.
Decision lead time
The time from when a decision becomes necessary until it is made. Long decision lead time can create a queue as costly as waiting for review, testing or an environment.
Decision Log
A lightweight record of significant decisions: what was decided, why, who decided and in what context. It reduces repeated discussions and loss of knowledge over time.
Decision rights
An explicit definition of who may make a given type of decision and where autonomy ends. Collaboration does not require universal consensus when final decision authority is clear.
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
A shared, unambiguous set of conditions defining when a piece of work can be considered genuinely complete.
Definition of Ready
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.
Definition of Workflow
An explicit description of how work moves through the system: where it starts and ends, which states it passes through and which policies govern selection, WIP, blockers and handling of work.
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
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
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
Empiricism
An approach based on transparency, inspection and adaptation: decisions use observed evidence and the way of working changes when new information appears.
Endpoint
A specific address or operation exposed by an API where a system accepts defined requests.
End-to-end
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.
Evidence
Information, observation or result that strengthens or weakens a hypothesis and can change a decision. In the book it contrasts with relying only on belief or ritual.
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.
Expedite
An exceptional class of service for work requiring immediate action because of serious impact or risk. It should be rare, explicit and governed by clear criteria because it interrupts normal flow.
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.
First-party source
Material published by an organisation describing its own principles, practices, tools or ways of working. In the book such sources are practical benchmarks rather than standards to copy verbatim.
Fixed Date
A class of work for which missing a specific date has a real legal, contractual, operational or market consequence. It requires an explicit date, owner and early risk tracking.
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.
Flow metrics
A set of measures describing work-flow behaviour, especially WIP, Throughput, Work Item Age and Cycle Time. They should support system decisions rather than rank individuals.
Flow Review
A periodic review of the whole work system using WIP, cycle time, work age, throughput, blockers and queue data. It is used to adapt policies and system constraints.
Focus time
Protected time reserved for work requiring concentration and sustained context. Its value falls when the day is fragmented by many short meetings and interruptions.
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.
Guardrail metric
A metric used to ensure that improving one outcome does not damage another important dimension such as quality, stability or team health.
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.
Hero mode
An exceptional mode of work based on extraordinary effort, overtime and individual rescue actions. It may be needed in a crisis, but recurring hero mode signals a system problem.
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.
Improvement Backlog
A visible set of candidates for changing the way of working. It should be prioritised and constrained like other work rather than become an ever-growing list of retrospective ideas.
Improvement debt
The accumulating cost of postponing known improvements to the work system. It grows when problems are repeatedly identified but capacity is not allocated to address them.
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.
Interrupt
An unplanned event that pulls a person or team away from current work, such as an incident, urgent request, consultation or priority change. Its source and cost should be managed rather than assumed unavoidable.
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.
Kanban Guide
The canonical guide describing Kanban, including Definition of Workflow, explicit policies, WIP control, pull, active management of work and core flow metrics.
Key Performance Indicator
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.
Lessons Learned
A structured capture of learning after an important event, project, experiment or success. It creates value when the learning changes future decisions or ways of working.
Little's Law
A relationship between average WIP, throughput and average flow time in a stable system. It helps explain why excessive work in progress increases delivery time and should not be turned into an artificial KPI without checking its assumptions.
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.
Meeting debt
The accumulating cost of meetings that remain on the calendar after losing their purpose, duplicating other channels or outliving a change in the work system. It requires periodic review and removal.
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.
No Estimates
An approach that reduces or removes estimation of individual work items where historical data, small comparable items and flow metrics are sufficient. It does not mean abandoning forecasting or planning accountability.
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.
Outcome
A change in user behaviour, business result, risk or system behaviour that we want to achieve. It answers what should change, not merely what will be built.
Output
What has been produced or delivered, such as a feature, report, API or migration. An output can be delivered correctly without producing the intended outcome.
Ownership
Responsibility for driving an issue to an outcome, decision or next step rather than only completing an assigned part. Shared team ownership does not remove the need for clear owners of specific decisions and initiatives.
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.
Planning Poker
A group relative-estimation technique in which participants choose values independently and differences trigger discussion about understanding and risk. The technique is a tool, not the goal of estimation.
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.
Product Owner
The Scrum accountability concerned with maximising product value and effective Product Backlog management. In the book the role title does not remove the team's responsibility to understand the problem and shape the solution.
Progressive delivery
A way of releasing changes gradually to controlled groups or portions of traffic while observing results and limiting risk.
Proof of Concept
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.
Psychological safety
A condition in which people can surface problems, ask questions, admit uncertainty and raise risks without fear of punishment merely for speaking up.
Pull
A principle in which new work is taken when real capacity becomes available at the relevant point in the workflow, rather than being assigned regardless of current load.
Pull request
See: Merge request
Push
Starting or assigning new work regardless of whether downstream capacity is available to handle it. It tends to increase WIP and queues.
QA
See: Quality Assurance
QE
See: Quality Engineering
Quality Assurance
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
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.
Ready enough
A state in which enough is known to start work responsibly and the remaining uncertainty is visible and acceptable. It does not mean a complete specification or the end of learning.
Ready Queue
A limited set of items prepared for near-term selection. An oversized Ready Queue turns preparation into a warehouse of ageing specifications.
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.
Relative sizing
Assessing work size by comparing it with other known items rather than assigning hours directly. It can reveal differences in understanding but remains an approximation.
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.
Replenishment
The mechanism or cadence for selecting the next work into a flow system. It serves a similar decision purpose to short-term planning without requiring work to be packaged into Sprints.
Responsible, Accountable, Consulted, Informed
A responsibility model identifying who is Responsible, Accountable, Consulted and Informed for a task or decision.
Retrospective
One of the team's learning loops used to inspect the way of working and choose improvements. The conversation alone is not success; decisions, actions and later verification matter.
Review / Sprint Review
A review of the achieved result and an opportunity to obtain feedback and adapt direction. It should not be merely a demonstration or formal acceptance ceremony.
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.
Scope
The set of things planned within a goal, initiative or period. Scope is a means to achieve an outcome and may change when new information appears or time is fixed.
Scrum
A lightweight framework for developing complex products using Sprints, defined accountabilities, events and artefacts.
Scrumban
A convenient label for a model combining selected Scrum and Kanban mechanisms, such as an iterative goal and cadence with pull, WIP and ageing. It is useful when the combination solves concrete problems rather than preserving every ritual from both approaches.
Scrum Guide
The canonical document describing Scrum’s accountabilities, events, artefacts and rules.
SDLC
Secure Software Development Life Cycle
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.
Self-service
The ability to perform a needed action without waiting for a central specialist, team or manual approval. Good platforms, tools and contracts increase independence through safe self-service.
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
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 Expectation
An expectation for work completion time based on historical system behaviour. It is not a guarantee or SLA; it helps identify ageing work and respond to risk earlier.
Service Level Indicator
A measurable indicator of service quality, such as availability, latency or the percentage of successful operations.
Service Level Objective
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.
Silo
An organisational or skill boundary that makes work wait for the next function while responsibility ends at the handoff. Specialisation is useful; a silo exists when it obstructs shared completion of the outcome.
Site Reliability Engineering
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
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.
SPACE
A multidimensional model of developer productivity covering Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow. It warns against judging a work system by one activity metric.
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.
Sustainable pace
A way of working the team can sustain over the long term without chronic overtime, constant overload or recurring hero mode. It does not mean working slowly but maintaining stable capability.
Swarming
Several people focusing together on finishing work already in progress instead of automatically starting new items. It helps break local queues and supports finish-before-starting behaviour.
Target
A desired result or date we would like to reach. A target gives direction but is not itself a probability-based forecast or commitment.
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 Agreements / Working Agreements
A lightweight set of agreed collaboration rules, such as communication channels, review expectations, interruption handling, focus time or escalation. They should describe real behaviour and evolve with the team.
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.
Team Health
Qualitative and quantitative signals showing whether the way of working is sustainable and whether the team has conditions for collaboration, focus and surfacing problems. It is not an evaluation of individuals or a team ranking.
Team Operating Model
The team's agreed day-to-day operating system: goals, work intake, priorities, readiness, flow, capacity, decisions, communication, meetings, dependencies and learning. It should answer real operational decisions rather than only describe ceremonies.
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.
Timebox
A fixed amount of time reserved for an activity, experiment or decision. A timebox limits cost and creates a review point; it does not imply all problems can be solved in identical time.
Trade-off
A decision in which improving one dimension requires accepting a cost in another, such as scope, time, risk, quality or flexibility. Mature planning makes that cost visible instead of promising everything at once.
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
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
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)
The 50th percentile: half of observed cases are at or below this value and half are above it.
85th percentile (P85)
The 85th percentile: 85 percent of observed cases are at or below this value.
90th percentile (P90)
The 90th percentile: 90 percent of observed cases are at or below this value.
95th percentile (P95)
The 95th percentile: 95 percent of observed cases are at or below this value.
99th percentile (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.