ITIL 4 HVIT key terms

The application of ITIL 4 practices at speed and scale to co-create value in fast-moving, digitally enabled environments where customer expectations, technology change, and competitive pressure demand rapid, safe delivery of products and services.

A setting characterised by volatility, uncertainty, complexity, and ambiguity, where cause and effect are unclear and past experience is an unreliable guide, requiring organisations to sense, respond, and adapt continuously rather than plan in detail.

An enterprise whose products, services, and operating model are built on digital technology, so that software and data are central to how it creates and captures value rather than supporting a primarily physical business.

Sustained organisational change in strategy, structure, culture, and capability, enabled by digital technology, that alters how value is created for customers and how work is organised and governed.

A product whose value depends on software and data, delivered continuously, with a lifecycle from concept through retirement, and managed as a whole rather than as a set of separate projects and handovers.

The series of steps an organisation uses to create and deliver value to a customer, including the flow of work, information, and decisions, mapped end to end to expose delays, handovers, and waste.

A visual technique that charts the steps, queues, and handovers in a value stream, with timing and quality data, to identify waste and constraints and to design a faster, more reliable flow of value.

The smooth, uninterrupted movement of work through a value stream, with work pulled as capacity allows, small batch sizes, and minimal queues, so that value reaches the customer quickly and predictably.

The total elapsed time from when a customer requests something to when it is delivered, including all waiting, which is the measure customers experience and the primary target for improvement in high-velocity value streams.

The time taken to complete one unit of work once it has started, or the interval between successive completions, used to understand capacity and predict how quickly work will be finished.

A relationship stating that average lead time equals average work in progress divided by average throughput, so reducing work in progress or raising throughput shortens the time work spends in the system.

The amount of work started but not yet finished at a given moment; limiting it is a core tactic for reducing queues, improving flow, and exposing bottlenecks in a value stream.

A visual method for managing work by making items and their states visible on a board, limiting work in progress, and managing flow and feedback so that capacity and demand stay in balance.

The practice of displaying work status, metrics, and problems where the team can see them, so that information is shared without asking, anomalies are obvious, and decisions can be made quickly.

A large, visible display of key team information such as flow, quality, and progress, placed where the team and stakeholders pass it, so that status is understood at a glance without meetings or reports.

A set of values and principles favouring small, cross-functional teams, short feedback cycles, working software, and responsiveness to change over comprehensive upfront plans and heavy documentation.

An agile framework using fixed-length iterations called sprints, defined roles, and artefacts such as a product backlog, with short ceremonies that plan, inspect, and adapt the work and its outcomes.

An ordered list of everything that might be built for a product, continuously refined and reordered by the product owner so that the most valuable items are delivered first.

A shared, explicit checklist of criteria that a work item must meet before the team considers it complete, ensuring quality is built in and preventing work from being declared finished prematurely.

The smallest version of a product that delivers enough value to real customers to test key assumptions and generate learning, used to reduce risk before investing in fuller features.

A collaborative way of working that unites development and operations around shared goals, automation, and end-to-end flow, so that software can be delivered frequently and reliably into production.

A practice in which developers merge code changes into a shared mainline frequently, with automated builds and tests on each merge, so integration problems are found and fixed within minutes.

A practice keeping software in a state where it can be released to production at any time, through automated build, test, and deployment pipelines and small, frequent changes.

The automated sequence of build, test, and deployment steps that takes a code change from commit to production, providing fast feedback and repeatable, low-risk releases.

The technical act of installing and activating a new or changed version of software in an environment, which is distinct from releasing it to users and can be decoupled from that release decision.

The making available of a new or changed product or service to users, which may be separated from deployment so that code can be in production while its effect on users is controlled.

A release technique running two identical environments, switching traffic from the live one to the newly deployed one, so changes go live with minimal downtime and can be rolled back quickly.

A technique that sends a small proportion of live traffic to a new version first, monitors its behaviour, and gradually increases exposure, limiting the impact of defects on the wider user base.

A configuration switch in code that enables or disables functionality at runtime without redeploying, allowing releases to be decoupled from deployment and features to be tested or withdrawn quickly.

A technique where a failing automated test is written before the code that makes it pass, followed by refactoring, producing designed-in quality and a regression suite that supports frequent change.

The use of tooling to execute checks on software without manual intervention, providing fast, repeatable evidence of quality on every change and reducing the cost and risk of frequent releases.

An approach that applies software engineering to operations, using service level objectives, error budgets, automation, and blameless analysis to balance reliability against the pace of change.

A measurable target for a specific aspect of service performance, such as availability or latency, agreed internally and used to guide operational decisions and prioritise reliability work.

A defined quantitative measure of a service's performance, such as the proportion of requests served successfully, from which objectives are set and reliability is tracked.

The amount of unreliability a service may experience within a period, derived from its objective, which teams spend on change and innovation and use as a trigger to slow down when exhausted.

The ability to understand a system's internal state from its external outputs, such as logs, metrics, and traces, so that unexpected behaviour can be diagnosed quickly without guesswork.

A structured review after an incident that focuses on systemic causes and learning rather than individual fault, encouraging honest reporting and reducing the chance of recurrence.

A way of working that values respect for people, continuous improvement, and the elimination of waste, with everyone empowered to surface problems and improve the work they do.

The practice of continuous, incremental improvement carried out by the people doing the work, aiming for small, frequent gains rather than occasional large change programmes.

A regular team meeting to inspect how work was done, identify what helped and hindered it, and agree concrete improvements to try in the next period, supporting continuous learning.

A team climate in which people feel able to speak up, admit mistakes, ask questions, and challenge decisions without fear of punishment or humiliation, enabling fast learning and honest feedback.

A leadership style that puts the needs of the team and customers first, removing obstacles, providing direction and coaching, and enabling autonomy rather than directing through command and control.

A stable, cross-functional group with end-to-end responsibility for a digital product, empowered to decide how to meet customer needs and accountable for outcomes rather than output.

The role accountable for maximising the value of a product, owning and ordering the backlog, defining acceptance criteria, and making trade-off decisions about what is built and in what order.

A property of systems that improve when subjected to stress, shocks, and variability, achieved through decentralised decision-making, slack, diversity, and rapid feedback rather than rigid protection.

A system of many interacting agents whose behaviour emerges from local interactions and cannot be fully predicted or controlled from the top, requiring experimentation and sensing rather than detailed planning.

A sense-making model that classifies situations as clear, complicated, complex, or chaotic, each calling for a different response, such as best practice, expert analysis, safe-to-fail experiments, or decisive action.

The capacity of an organisation and its services to absorb disruption, continue operating, and recover quickly, supported by redundancy, tested response plans, and the ability to adapt under stress.