DPBoK Foundation key terms

A person who applies digital technology and digital ways of working to create value, combining technical skill with awareness of business context, customer needs, and the pace of continuous change.

Sustained organizational change in strategy, processes, culture, and technology so that an enterprise operates and delivers value primarily through digital means rather than isolated IT projects.

A disposition that treats experimentation, fast feedback, and continuous learning as normal, accepting that products evolve and that failure is information rather than a career risk.

A structured, curated collection of concepts, practices, and reference material for a professional field, organized so practitioners can locate guidance by topic rather than by chronology.

A durable offering that a team owns end to end, delivering value to customers over time and evolving through continuous feedback rather than being finished and handed off.

A small, cross-functional group with the skills and authority to design, build, operate, and improve a product, accountable for outcomes rather than for completing assigned tasks.

A team whose members collectively hold the range of capabilities needed to deliver an outcome without depending on other groups for routine work.

The end-to-end sequence of activities that turns a customer need into delivered value, examined to find delays, handoffs, and waste that slow the flow.

A visual technique that charts each step, wait, and handoff in a value stream, making cycle times and bottlenecks visible so improvement effort targets the real constraint.

The total elapsed time from when a request or need is raised until value is delivered to the customer, including all waiting between work steps.

The time taken to complete one unit of work once active work on it has started, excluding time spent queued before work began.

The smooth, uninterrupted movement of work through a system, achieved by limiting work in progress, reducing batch sizes, and removing queues and handoffs.

A cap on how many items may be actively in progress at once, used to expose bottlenecks, shorten queues, and keep teams finishing work rather than starting more.

A method for managing continuous flow that visualizes work on a board, limits items in progress, and uses measured throughput and cycle time to guide improvement.

A family of iterative delivery approaches that favor short cycles, working increments, customer collaboration, and responsiveness to change over heavy upfront specification.

A fixed, short timebox in which a team designs, builds, tests, and reviews an increment of work, producing feedback that informs the next timebox.

A usable, potentially deliverable addition to a product produced within an iteration, complete enough to be evaluated by users or stakeholders.

The smallest version of an offering that lets a team test key assumptions with real users, trading completeness for fast, low-cost learning.

An ordered, evolving list of desired product changes and work items, maintained by a product owner and refined continuously as understanding improves.

The role accountable for maximizing product value by ordering the backlog, clarifying intent, and deciding what the team works on next.

A set of practices and cultural norms that unite development and operations so software can be built, tested, released, and operated with high frequency and reliability.

The practice of merging every developer's changes into a shared mainline frequently, with automated build and test checks verifying each merge.

A discipline in which software is kept in a releasable state at all times through automated build, test, and deployment pipelines, so release is a routine decision.

An automated sequence of build, test, and environment-provisioning stages that moves a change from commit toward production, failing fast when quality gates are missed.

Use of scripted test suites that run without manual intervention to verify behavior quickly and repeatedly, giving teams confidence to change code often.

An operations discipline that applies software engineering to running systems, using service level objectives, error budgets, and automation to balance reliability against change.

A measurable target for a reliability or performance characteristic of a service, such as availability percentage over a defined window, used to judge whether service is acceptable.

A quantitative measure of service behavior, such as request latency or success rate, that provides the raw data against which a service level objective is compared.

The amount of unreliability a service may tolerate within a period, derived from its objective, which governs how much risk-taking and change release is allowed.

An architectural style that decomposes a system into small, independently deployable services, each owning a bounded capability and communicating over well-defined interfaces.

A defined contract through which one software component requests data or behavior from another, hiding internal implementation and enabling independent evolution.

A discrete, independently operated capability exposed to consumers through a stable interface, with its own lifecycle, ownership, and reliability expectations.

A lightweight, isolated runtime package bundling an application with its dependencies, so it behaves consistently across environments and starts quickly.

Automated scheduling, scaling, and management of many containerized workloads across a cluster, handling placement, restarts, and networking without manual intervention.

Managing servers, networks, and platform configuration through versioned, machine-readable definition files so environments are reproducible and changes are reviewable.

On-demand delivery of computing resources over a network with self-service provisioning, elasticity, and measured pay-per-use billing, reducing the need to own hardware.

The accumulated cost of shortcuts and outdated design that make future change slower or riskier, repaid through deliberate refactoring and improvement work.

Improving the internal structure of existing code without changing its observable behavior, keeping design fit for continued change.

A choice grounded in measured evidence such as usage metrics or experiment results, rather than in opinion or seniority alone.

A controlled test that changes one variable for a subset of users and compares outcomes against a baseline, producing evidence about cause and effect.