CASM cheat sheet

Agile Manifesto values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan - the right-hand items retain value, only the left is prioritized.

Lean thinking's five principles: specify value from the customer's perspective, map the value stream, create flow, establish pull, pursue perfection.

The seven Lean wastes (TIMWOOD): Transport, Inventory, Motion, Waiting, Overproduction, Overprocessing, Defects; service variants add unused talent and unused capacity.

Agile service management applies iterative, incremental delivery and continuous feedback to the design, transition, and operation of services, rather than treating service management as a single waterfall program.

Definition of Done vs. acceptance criteria: acceptance criteria define fitness of a single backlog item; the Definition of Done is the shared quality bar applied to every increment.

Push vs. pull: push systems schedule work by forecast and create queues; pull systems authorize new work only when downstream capacity frees up.

A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without owning specific costs and risks.

Empirical process control (Scrum) rests on three pillars - transparency, inspection, adaptation - and is appropriate when requirements and technology are not fully predictable.

Readiness assessment dimensions: leadership sponsorship, team skills and cross-functionality, tooling and automation, data availability, and cultural tolerance for iterative change.

Crawl–walk–run–fly progression: pilot one value stream or service with a small, co-located, cross-functional team before scaling to additional teams.

A transformation backlog is a prioritized, visible list of improvement items with an owner and a Definition of Done, managed like product work rather than a project plan.

Burning-platform indicators that justify change: rising change failure rate, long lead time, backlog of unplanned work, key-person dependency, and high cost of compliance evidence.

Readiness gate questions: can we deliver a thin slice to a real user within one iteration? Do we have a product owner with decision authority? Can we measure lead time today?

Value-stream selection criteria for a first pilot: high pain, low dependency on other teams, visible customer, and a sponsor willing to protect the team from interrupt work.

Resistance patterns map to roles: middle management fears loss of control, specialists fear deskilling, audit functions fear loss of evidence - each needs a different countermeasure.

Adoption is measured by behavior change (frequency of releases, WIP limits honored, retrospectives producing actions), not by training completion or tool rollout.

User story form: As a , I want , so that ; the 'so that' clause carries the value and is not optional.

INVEST criteria for stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Story splitting patterns: workflow steps, business rule variations, data entry versus display, happy path versus edge cases, and interface/platform splits.

Three amigos: business, development, and testing perspectives review a story together before development to surface ambiguity and produce concrete examples.

Example mapping structure: a story card, then rule cards (acceptance criteria), then example cards (concrete scenarios), then question cards (open unknowns).

Given/When/Then (Gherkin) turns an example into an executable acceptance test: Given the precondition, When the action, Then the expected observable outcome.

A service blueprint extends journey mapping with frontstage actions, backstage actions, support processes, and physical/digital evidence at each step, exposing failure points.

Non-functional requirements for services - availability, capacity, continuity, security, and information security controls - are written as measurable acceptance criteria, not as prose appendices.

Deployment pipeline stages: build, unit test, automated acceptance test, security and compliance scanning, artifact versioning, environment promotion, release.

Deployment vs. release: deployment places an artifact in an environment; release exposes it to users. Decoupling them enables dark launches and feature flags.

Blue-green deployment switches traffic between two identical environments; canary release routes a small percentage of traffic to the new version and expands on healthy signals.

Rollback decisions are pre-authorized by defined health thresholds (error rate, latency percentile, business KPI) so that recovery does not wait for a change advisory board.

Trunk-based development with short-lived branches reduces merge risk; long-lived feature branches increase integration cost and delay feedback.

Standard changes are pre-approved, low-risk, repeatable changes with a documented procedure; they bypass per-instance approval but remain recorded and audited.

Release and deployment management in an agile context shifts from gating individual changes to validating the pipeline that produces every change.

Service validation and testing levels: unit, integration, system, acceptance, and operational readiness - the last confirming support staff can run the service before go-live.

Value stream mapping steps: select the product or service family, map the current state, calculate flow metrics, identify waste, design the future state, and define a improvement backlog.

Lead time = time from request/customer order to delivery; process time = sum of value-adding work time; flow efficiency = process time ÷ lead time × 100%.

Little's Law: average work in progress = throughput × average cycle time (WIP = TH × CT); it holds for a stable system and lets you predict any one variable from the other two.

Queueing effects: at 80% utilization, waiting time grows sharply; at 90% it roughly doubles versus 80%, so service teams cap utilization to protect lead time.

Value-adding, business-value-adding, and non-value-adding steps: only the first is what the customer pays for; business-value-adding steps are removed only by changing policy or regulation.

Kaizen is continuous incremental improvement by the people doing the work; kaikaku is radical redesign of the process; both feed the same improvement backlog.

A3 problem solving: background, current condition, target condition, root cause analysis, countermeasures, plan, and follow-up on one page.

DMAIC ordering (Define, Measure, Analyze, Improve, Control) is used when a value stream problem needs statistical verification; PDCA (Plan, Do, Check, Act) is the shorter loop for iterative experiments.

Kanban core practices: visualize the workflow, limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively and evolve experimentally.

Scrum events and timeboxes: Sprint (1 month or less), Sprint Planning, Daily Scrum (15 minutes), Sprint Review, Sprint Retrospective.

Scrum accountabilities: Product Owner (value and ordering), Scrum Master (effectiveness of the Scrum Team), Developers (the increment); the Scrum Team is cross-functional and self-managing.

Kanban classes of service - expedited, fixed date, standard, intangible - each get a distinct policy and, where needed, a dedicated swimlane or capacity allocation.

Cumulative flow diagram reading: widening vertical band = growing WIP; flat horizontal band = blocked flow; the slope of a band estimates throughput.

Cycle time distribution beats averages: report the 50th, 85th, and 95th percentiles so commitments reflect a service level rather than a mean that hides variability.

Scrumban combines Scrum's cadence and roles with Kanban's WIP limits and pull-based replenishment, common where support interrupt work dominates.

Blocked work is made visible with a blocker flag and an explicit policy for escalation time; blocked time is excluded from process time but included in lead time.

The Three Ways: flow (accelerate left-to-right delivery), feedback (amplify right-to-left learning loops), and continual experimentation and learning.

CALMS framework dimensions: Culture, Automation, Lean, Measurement, Sharing - used as a diagnostic checklist for DevOps adoption.

You build it, you run it: the team that writes the service also carries its operational pager and reliability objectives, aligning incentives for quality.

Blameless postmortem structure: timeline, contributing factors, detection and response analysis, action items with owners and due dates; it targets system conditions, not individuals.

Automation priority order: repetitive high-frequency manual steps first, then steps that are error-prone, then steps that gate release speed.

Infrastructure as code requires version control, peer review, automated testing, and idempotent provisioning so environments are reproducible and auditable.

Shift left means moving quality, security, and compliance checks earlier into the pipeline as automated gates rather than late-stage reviews.

Toil is manual, repetitive, automatable, tactical work that scales linearly with service growth; it is measured as a percentage of operational time and capped.

DORA delivery metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service (failed deployment recovery time).

Flow metrics: WIP, throughput, cycle time, lead time, flow efficiency, and work item age; work item age is the elapsed time since an item started, used to spot items at risk.

Velocity is a team-internal planning measure in story points; it is not comparable across teams and must not be used as a productivity target.

Service level indicator is the measured signal; service level objective is the target range; service level agreement is the contract with consequences; error budget = 1 − SLO.

Goodhart's law: when a measure becomes a target it ceases to be a good measure - so pair every metric with a counter-metric to prevent gaming.

Outcome over output: measure customer and business results (adoption, task success, availability) alongside delivery activity, since activity metrics alone invite local optimization.

Percentile reporting: use p50/p95/p99 latency rather than averages, because averages hide the tail that users actually experience.

Metrics hierarchy: team-level operational metrics roll up into service-level objectives, which roll up into business outcome indicators reported to leadership.

Governance in agile delivery is achieved through guardrails and automated evidence, not through stage gates that stop work at each phase.

Segregation of duties can be preserved in a pipeline by separating the roles that author, approve, and deploy, with approvals recorded as automated attestations.

Risk treatment options: avoid, reduce, transfer, accept; each accepted risk needs an owner, a rationale, and a review date.

Policy as code embeds control requirements (encryption, logging, access) as automated tests, giving continuous compliance evidence rather than annual sampling.

Audit trail requirements: every change traceable to a request, an approval, a test result, and a deployed artifact version, retained per the applicable retention policy.

Separation of the change authority from the change implementer matters most for high-risk changes; standard and low-risk changes can be pre-authorized by policy.

Regulatory and contractual obligations (data protection, financial controls, sector rules) become non-functional requirements in the backlog, not separate documents written after delivery.

Continuous control monitoring replaces periodic point-in-time audit with automated checks that flag drift, reducing the cost of evidence collection.

Kotter's eight steps: urgency, guiding coalition, vision, communicate, empower action, short-term wins, consolidate gains, anchor in culture.

ADKAR sequence is individual: Awareness, Desire, Knowledge, Ability, Reinforcement - change fails at the first gap, so diagnose which element is missing rather than training everyone.

Change curve stages (denial, resistance, exploration, commitment) predict that productivity dips after the announcement; plan for the dip instead of treating it as failure.

Change saturation: measure the number of concurrent changes affecting the same group; beyond capacity, adoption falls even when each change is well designed.

Transformation office function shifts from controlling projects to maintaining the improvement backlog, publishing metrics, and removing systemic blockers.

Sponsor behavior is the strongest predictor of adoption: visible participation in reviews and retrospectives outweighs communications campaigns.

Metrics of transformation: lead time trend, change failure rate trend, percentage of work that is planned versus unplanned, and retrospective action closure rate.

Anchoring requires changing formal mechanisms - job descriptions, budgeting, performance review, and onboarding - so the new way survives leadership turnover.