CASM key terms

Applying agile and lean principles to the design, delivery, and improvement of IT services, so that work is organized around customer value, short feedback loops, and continuous adaptation rather than rigid long-cycle plans.

A management approach that maximizes customer value by systematically removing waste, limiting work in progress, and improving flow through small, incremental changes made by the people doing the work.

Any activity that consumes resources without creating value for the customer. Common examples in service work include waiting, handoffs, rework, partially done work, and unnecessary approval steps.

The end-to-end sequence of activities, people, and systems required to move a customer request from initial demand to delivered value, including both value-adding steps and the delays between them.

A collaborative technique that visualizes the steps, queues, and handoffs in a value stream, quantifies process time versus wait time, and identifies the largest sources of delay for improvement.

The ratio of active work time to total elapsed time for a work item, expressed as a percentage. Low flow efficiency signals that items spend most of their life waiting rather than being worked on.

The total elapsed time from the moment a customer raises a request or a work item enters the system until it is delivered. It measures the customer's actual experience of waiting.

The elapsed time between a work item starting active work and being completed, or the average interval between successive items leaving a process. Often used for predictability forecasting.

A queuing relationship stating that average work in progress equals average throughput multiplied by average lead time. It lets teams predict how limiting WIP or raising throughput changes waiting time.

The number of work items that have been started but not yet finished. Limiting WIP is a core flow practice because excess started work increases queues, context switching, and delivery delay.

An explicit cap on how many items may occupy a workflow stage at one time. When the cap is reached, the team swarms to finish existing work rather than pulling new work in.

A visual representation of a workflow with columns for stages and cards for work items, showing current state, blockers, and policies so that flow problems become visible to everyone.

A way of scheduling work in which an item is started only when downstream capacity becomes available, rather than being pushed into the process by a plan or a queue of commitments.

The number of work items completed per unit of time, such as tickets closed per week. It is a core flow metric used with lead time to forecast future delivery without estimating individual items.

A stacked-area chart showing how many items sit in each workflow stage over time. Widening bands reveal growing queues and bottlenecks, while stable bands indicate predictable flow.

An agile framework in which a small cross-functional team delivers increments in fixed-length sprints, using a product backlog, sprint planning, daily inspection, a review, and a retrospective.

A fixed timebox, typically one to four weeks, during which a Scrum team builds a usable increment. Scope is protected during the sprint so that goals can be met and learning captured.

An ordered list of everything that might be built to improve the product or service, refined continuously by the product owner so the highest-value items are ready for upcoming work.

A short, plain-language statement of a need written from the user's perspective, usually with a role, a goal, and a benefit, intended to spark conversation rather than fully specify a solution.

The specific, testable conditions a work item must satisfy to be accepted by the customer or product owner. They clarify scope and form the basis for verification and automated tests.

A shared checklist describing what quality and completeness mean for any increment, such as tested, documented, and deployed. It prevents items from being declared complete prematurely.

An agreed set of criteria a backlog item should meet before a team pulls it into work, for example clear value, understood dependencies, and testable acceptance criteria.

The smallest version of a service that delivers real value to early users, released to validate assumptions and gather feedback before investing in wider scope and scale.

The discipline of shaping a service's components, interactions, and touchpoints so that it meets customer outcomes and is deliverable, supportable, and measurable end to end.

A diagram mapping the customer journey against front-stage interactions, back-stage activities, and supporting systems, exposing dependencies and failure points across the whole service.

The sequence of steps and emotions a customer experiences while trying to achieve an outcome with a service, used to identify friction and moments that matter most.

The stages a service passes through from concept and design to build, transition, operation, and retirement, each with distinct decisions, risks, and governance needs.

One or more changes to a service made available to users together. Agile practice favors small, frequent releases so that risk and feedback are contained within each increment.

The technical act of installing and activating a version of software or configuration in an environment. Deployment can be separated from release so that features are activated independently.

A runtime switch that enables or disables functionality without redeploying code, allowing dark launches, gradual rollouts, and rapid rollback if a change misbehaves.

A deployment pattern in which a change is exposed to a small subset of users or traffic first, with monitoring, before being rolled out to the wider population.

A practice in which developers merge small code changes frequently and each merge triggers automated build and test, catching integration defects early and keeping the mainline releasable.

A practice that keeps software in a state where it can be released to production at any time, relying on automated testing and deployment pipelines rather than manual release projects.

The automated sequence of build, test, and deployment stages a change passes through on its way to production, providing fast feedback and consistent, repeatable verification.

A culture and set of practices that unite development and operations around shared ownership of delivery and reliability, emphasizing collaboration, automation, measurement, and continuous learning.

A structured review after an incident that focuses on systemic causes and contributing factors rather than individual fault, producing actionable improvements and shared learning.

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

A quantitative measure of a service's observed performance or reliability, such as request success rate or latency at a percentile, used as the raw signal for objectives and reporting.

A target range for a service level indicator, such as 99.9 percent availability over a month, defining what reliability the service promises internally to guide engineering decisions.

The amount of unreliability a service level objective permits in a period. Spending it on risky changes is allowed; exhausting it triggers a focus on stability over new features.

The practice of maximizing successful service changes by assessing risk, right-sizing approval and testing based on impact, and using automation and feedback to reduce failure and delay.

A low-risk, pre-authorized change type with a documented procedure and known outcome, allowing teams to execute it repeatedly without per-instance approval and with minimal delay.

A group that reviews and advises on higher-risk changes, weighing impact, readiness, and timing. In agile settings its role narrows to exceptional or high-impact changes rather than routine work.

The accumulated cost of shortcuts and deferred work in a product or service, which slows future change and raises failure risk unless made visible and deliberately repaid.

The practice of continuous, incremental improvement driven by the people who do the work, using small experiments and regular reflection to remove friction and raise quality over time.

A recurring team meeting at the end of a cycle to inspect how work was done, identify improvements, and commit to a small number of concrete changes for the next cycle.

A team climate in which people can raise concerns, admit mistakes, and challenge decisions without fear of punishment, enabling honest retrospectives and faster learning.

The degree to which an organization has the skills, structures, leadership support, and culture needed to adopt agile service management successfully, assessed before and during transformation.

A staged plan describing how an organization will move from current practices to target agile service management capabilities, including sequencing, pilots, milestones, and success measures.

A mechanism that returns information about the results of an action to the people who can act on it, such as monitoring, user testing, or reviews, enabling timely correction.

The decision rights, policies, and oversight that direct how services are funded, changed, and assured, ideally expressed as guardrails that enable fast delivery rather than gate-by-gate control.

A maintained record of identified risks with owners, likelihood, impact, and mitigation actions, used to make trade-offs visible and to feed prioritization decisions.

Expressing regulatory and policy controls as automated, versioned checks in the delivery pipeline, so evidence is generated continuously and drift is detected quickly.

Any component under configuration control that must be identified, versioned, and tracked because it contributes to a service, such as servers, applications, or documentation.