--- title: "AgileOps" slug: agileops category: product term_status: ambiguous evidence_status: verified summary: "AgileOps is an informal label with several published meanings and no standard. This page uses it for running agile delivery day to day: Scrum and Kanban, WIP limits, flow metrics, a shared Definition of Done and retrospectives that change something." audience: [Scrum Masters and delivery leads, Team leads and engineering managers, Operations and infrastructure teams, Product owners, Beginners] last_verified: 2026-10-23 key_takeaways: - "AgileOps has no owner, standard or certification. Published uses include a business operating model (TechTarget), an agile mindset shift for infrastructure teams (Cisco IT blog), a book on Agile, DevOps and SRE for cloud operations, and a 2010 synonym for DevOps." - "This Atlas uses the label for one job: running a team's agile working system — its cadence, its flow of work and its improvement loop. That emphasis is an editorial choice." - "Limiting work in progress is the highest-leverage habit. Finish before you start; when people are idle, help elsewhere rather than raising the limit." - "Always name the two timestamps behind a time metric. Kanban lead time, Kanban cycle time, tool-defined lead time and DORA's change lead time measure different spans." - "Forecast with ranges from your own history (percentiles, Monte Carlo), not with velocity comparisons; never compare teams or individuals on velocity." - "Choose the method by how work arrives: planned batches suit Scrum, unpredictable arrivals suit Kanban, and interrupt-heavy operations teams need protected interrupt capacity either way." - "Fix one team's flow before scaling. Frameworks such as SAFe and LeSS make very different bets, and copying another company's model has failed even at its source." related: [devops, projectops, portfolioops, productops, releaseops, designops, devexops, sre] --- ## What AgileOps is ### In 30 seconds **AgileOps** is not a defined discipline. It is a label that writers have used for at least four different ideas, from a "digital business operating model that builds on Agile methodologies and DevOps techniques"[^tt2022] to "a highly localised agile mindset shift for infrastructure teams".[^cisco2019] No foundation, standard or certification owns it, and one TechTarget article says plainly that it "has different definitions depending on who's marketing what".[^ttvs2022] **In one line: on this Atlas, AgileOps means operating agile delivery day to day — the cadence, flow and improvement loop of a team that does knowledge work.** The practices are well documented (the Agile Manifesto, the Scrum Guide, the Kanban Guide and the Kanban Method); this page teaches them as one working system that you run, measure and change. **Who it is for:** Scrum Masters, delivery and team leads, operations teams whose work arrives as interrupts, product owners who need honest forecasts, and beginners. ::: note Editorial distinction Team cadence and flow are taught here; single projects, investment choices, product discovery and CI/CD live on neighbouring pages ([below](#how-agileops-relates-to-other-ops)). No standard draws these lines; the Atlas chose them so each topic is taught once. ::: ### At a glance | Aspect | Summary | |---|---| | Goal | Predictable flow of valuable, finished work, and a team that improves how it works | | Users | Delivery teams (software, infrastructure, operations, data, design) and the people who request their work | | Scope here | Manifesto values and principles; Scrum roles, events and artifacts; Kanban practices and flow metrics; Definition of Done; retrospectives; scaling frameworks at a high level; anti-patterns | | Prerequisites | None. Helpful: having worked in a team that tracks work on a board | | Key outputs | A Definition of Workflow, a Definition of Done, WIP limits, a service level expectation, forecasts as ranges, an improvement backlog | | Term status | **Ambiguous** — several published meanings, none authoritative ([naming](#what-agileops-is-not)) | ### The problem it solves Teams rarely fail for lack of a method; they fail because the work system they actually run is invisible and overloaded: - **Too much started, too little finished.** Everyone juggles four items; everything is "almost done". - **Invisible work.** Chat requests, incidents and favours never reach the board, so plans are fiction. - **"Done" means different things**, and the rework appears weeks later. - **Interrupts destroy plans.** An infrastructure team commits to two weeks of work and spends half of it on unplanned requests. - **Forecasts are defended, not updated**, and **retrospectives change nothing**. The Manifesto names the remedies — frequent delivery, sustainable pace, regular reflection[^principles] — and Kanban adds the mechanics: an explicit workflow, controlled WIP and four flow metrics.[^kanbanguide] What the sources leave to you is the operating detail: who changes a WIP limit, what happens when an item ages past its expectation, how an ops team protects capacity for interrupts. That detail is this page's subject. | Before | After | |---|---| | Everyone works on several items at once | WIP limits per state; people swarm to finish | | Board shows planned work only | All work visible, interrupts in their own lane | | Dates are guesses defended in meetings | Forecasts as ranges ("85% by 29 September"), updated weekly | | Retros produce lists | Each retro yields one owned experiment with a measure | ### What AgileOps is not - **Not a standard or a certification.** No body owns the label. - **Not DevOps.** CI/CD and DORA metrics are on [DevOps](../devops/). A fast pipeline does not fix overloaded WIP, and good Kanban does not fix a slow pipeline. - **Not project control, investment management or release mechanics** — see [the neighbour table](#how-agileops-relates-to-other-ops). ::: caution Naming: four meanings in circulation 1. **A business operating model** combining Agile and DevOps across the organisation (TechTarget, 2022).[^tt2022] 2. **Agile principles applied to IT operations**, usually with Kanban, "likely a DevOps derivative for many enterprises" (TechTarget, 2022).[^ttvs2022] 3. **An infrastructure team's agile transformation**: break silos, infrastructure as code, new skills, DevOps (Cisco IT blog, 2019);[^cisco2019] a 2022 Apress book uses the label for Agile, DevOps and SRE in cloud operations.[^apress2022] 4. **An early name for DevOps.** In 2010 "Agile Operations" could mean "Same as DevOps", agile process techniques "like iterative development or even kanban/TPS" (TPS: the Toyota Production System), or automation.[^mueller2010] This page teaches meaning 2, broadened to any delivery team, because no other Atlas page owns it. For meanings 1 and 4 the nearest Atlas page is [DevOps](../devops/); for the infrastructure automation in meaning 3, [InfraOps](../infraops/). ::: ## Where AgileOps comes from and where it sits ### Origins and evolution The practices are older and better documented than the label: - **1990s–2001.** Scrum was developed in the early 1990s and first presented at OOPSLA in 1995.[^scrumguide] In February 2001 seventeen people from Extreme Programming, Scrum, DSDM, Crystal, Feature-Driven Development and other "lightweight" methods met at Snowbird, Utah, and wrote the *Manifesto for Agile Software Development*.[^history] - **2006–2010.** Kanban for knowledge work "mainly originated on a team at Corbis in 2006";[^kanbanguide] David Anderson's 2010 book became the basis of the Kanban Method.[^kanbanmethod] The first Scrum Guide appeared in 2010.[^scrumguide] - **2008–2010: agile meets operations.** Patrick Debois presented "Agile Infrastructure and Operations: How Infra-gile are You?" at Agile 2008;[^debois2008] by 2010 "Agile Operations" and "DevOps" were used interchangeably.[^mueller2010] "DevOps" won. - **2019–2022: the one-word label** appears in a Cisco blog, TechTarget and an Apress book, each with a different meaning.[^cisco2019][^tt2022][^apress2022] - **2020–2025: the guides keep moving.** The Scrum Guide is still the November 2020 edition;[^scrumguide] Jeff Sutherland, John Coleman and Ralph Jocham have since published a *Scrum Guide Expansion Pack* as an optional "companion to the 2020 Scrum Guide" — it is not part of the Guide, and Ken Schwaber is not among its authors.[^sgexp] The May 2025 Kanban Guide renamed "Kanban Measures" to "Flow Metrics" and deleted a reference to Kanban's immutability.[^kanbanguide] ### Glossary and mental model | Term | Meaning | |---|---| | Definition of Workflow (DoW) | Kanban Guide term for the explicit agreement: work items, start and finish points, states, WIP control, policies and an SLE[^kanbanguide] | | Commitment / delivery point | Kanban Method: where the team commits to an item, and where it is delivered[^kanbanmethod] | | WIP | "The number of work items started but not finished"[^kanbanguide] | | Throughput | "The number of work items finished per unit of time"[^kanbanguide] | | Cycle time | Kanban Guide: "The elapsed time between when a work item started and when a work item finished"[^kanbanguide] | | Work item age | Elapsed time from start to now for unfinished items[^kanbanguide] (this page treats it as the leading time metric; see [metrics](#metrics-and-kpis)) | | Lead time | Kanban Method: commitment point to completion;[^kanbanmethod] on this page: request to delivery | | Service level expectation (SLE) | A time plus a probability, e.g. "85% of work items will be finished in eight days or less"[^kanbanguide] | | Class of service | A policy for treating some items differently, e.g. "expedite"[^kanbanmethod] | | Sprint, Sprint Goal | Scrum's fixed-length event of "one month or less"; "the single objective for the Sprint"[^scrumguide] | | Definition of Done (DoD) | The quality bar an Increment must meet before it counts[^scrumguide] | | Velocity | Sum of estimates of stories completed in an iteration; "not itself a budget or a forecast"[^velocity] | **Mental model: a team is a queue that can learn.** Four levers shape what customers experience: how much you start (WIP), how big items are, how you treat different work (classes of service, interrupts) and how often you change your rules (retrospectives). Scrum and Kanban are two packages of those levers. Little's Law — average WIP equals arrival rate times average time in system — means that with steady arrivals, doubling WIP doubles the average time an item spends in the system.[^little2011] ### How AgileOps relates to other Ops ::: figure Four meanings of the label and the nearest Atlas page for each ```mermaid flowchart LR M1["1. Business model"]:::neutral --> D["DevOps"]:::neutral M4["4. 2010 DevOps synonym"]:::neutral --> D M2["2. Agile in ops work"]:::decision --> P["This page"]:::core M3["3. Infra team change"]:::neutral --> I["InfraOps"]:::neutral classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 ``` Text equivalent: The label has four published meanings. For meaning 1, a business operating model (TechTarget 2022), and meaning 4, an early synonym for DevOps (2010), the nearest Atlas page is DevOps. Meaning 2, agile methods in operations work, is the one this page takes, broadened to running any team's cadence, flow and improvement. For meaning 3, an infrastructure team's agile transformation (Cisco 2019), the nearest page is InfraOps. The table below lists the neighbouring pages this page hands off to. ::: | Neighbouring page | Shared ground | This page's focus | Go there when | |---|---|---|---| | [DevOps](../devops/) | Flow, small batches, feedback | Work management before and around the code | The constraint is the pipeline, testing or deployment | | [ReleaseOps](../releaseops/) | Cadence | Team cadence, not release scheduling | You need flags, canaries or release governance | | [ProjectOps](../projectops/) | Plans and dates | Adaptive team flow | Scope is fixed and you report variance against a baseline | | [PortfolioOps](../portfolioops/) | WIP limits, prioritisation | WIP inside one team | You decide which initiatives get teams at all | | [ProductOps](../productops/) | Backlogs, cadences | Delivering what is ordered | You decide *what* to build and measure outcomes | | [DesignOps](../designops/), [DevExOps](../devexops/) | Rituals; interruptions | Team cadence and flow | Design craft and systems; developer experience broadly | | [SRE](../sre/) and [IncidentOps](../incidentops/) | Interrupt load | Protecting planned work from interrupts | You handle live incidents or set SLOs | ## Principles and operating model ### Charter and principles AgileOps has no official text; the closest shared foundation is the Agile Manifesto's four values and twelve principles. The values are "Individuals and interactions over processes and tools", "Working software over comprehensive documentation", "Customer collaboration over contract negotiation" and "Responding to change over following a plan"; "while there is value in the items on the right, we value the items on the left more".[^manifesto] Three principles carry most of the operating weight: "Working software is the primary measure of progress", "a constant pace indefinitely", and regular reflection on "how to become more effective".[^principles] ::: decision A proposed team charter (Atlas proposal, not an official document) **Mission.** Deliver valuable, finished work at a pace we can sustain, and get measurably better at it every month. 1. **Stop starting, start finishing.** Pull new work only when WIP is below the limit. 2. **One meaning of done.** Every item meets the written Definition of Done before it counts. 3. **All work is visible**, including interrupts, support and improvement work. 4. **Measure the system, never the person.** 5. **Forecasts are ranges with a probability**, updated as data arrives. 6. **Every retrospective ends with one owned experiment.** 7. **Fit the method to how work arrives**, not to fashion. **Non-goals.** Maximising utilisation; standardising every team's board; certifying anyone as "AgileOps". ::: ### Building blocks | Block | Minimum viable version | |---|---| | Work item types | 3–5 types with plain names (request, change, defect, improvement) | | Backlog (options) | One ordered list per team | | Workflow states | Only steps where work waits or changes hands | | Policies | WIP limits, pull rules, classes of service, DoD — written next to the board[^kanbanmethod] | | Cadences | Daily flow check, replenishment, retrospective | | Timestamps | Start and finish dates at least | | Improvement backlog | One active experiment | ### Roles, ownership and RACI **Scrum** defines three accountabilities — Developers, a Product Owner accountable "for maximizing the value of the product" and a Scrum Master accountable "for the Scrum Team's effectiveness" — in a team "typically 10 or fewer people".[^scrumguide] The **Kanban Guide** defines no roles,[^kanbanguide] and the **Kanban Method** encourages "acts of leadership at all levels".[^kanbanmethod] Without Scrum, someone must still facilitate and order the work; name who. | Activity | Product owner / requester lead | Team members | Scrum Master / delivery lead | Engineering manager | Stakeholders | |---|---|---|---|---|---| | Order the backlog | A/R | C | C | I | C | | Set or change a WIP limit | C | A/R | C (facilitates) | I | I | | Write and evolve the DoD | C | A/R | C (facilitates) | C | I | | Decide how to do the work | I | A/R | I | I | – | | Facilitate retrospectives | C | R | A/R | I | – | | Publish forecasts | A | R | R | I | I | | Approve an expedite item | A | C | R | I | C | R = responsible, A = accountable, C = consulted, I = informed. **The table is this Atlas's proposal**, aligned with the sources: in Scrum, an organisational Definition of Done, where one exists, is the minimum; otherwise "the Scrum Team must create a Definition of Done appropriate for the product", and "The Developers are required to conform to the Definition of Done".[^scrumguide] The Kanban Method says WIP limits "need to be agreed to by everyone actively involved".[^kanbanmethod] The facilitator helps the team decide; it does not decide for it. In Scrum, only the Product Owner may cancel a Sprint.[^scrumguide] ### Lifecycle: design, start, run - **Day 0 — design the system.** The Kanban Method's STATIK (Systems Thinking Approach To Introducing Kanban) is a good checklist: identify sources of dissatisfaction, analyse demand, analyse system capability, model the workflow, identify classes of service, then design the system. Kanban University reports it usually takes "between 4 hours and 4 days".[^kanbanmethod] Write the Definition of Workflow and the DoD. - **Day 1 — start.** Every current item on the board, interrupts included; dates recorded; first WIP limits ([playbook](#playbook-setting-and-holding-wip-limits)). - **Day 2 — run and improve.** Daily flow checks, regular replenishment, retrospectives and a monthly look at the metrics. Change policies when evidence says so; the Kanban Guide says there is "no requirement" to wait for a formal meeting to do it.[^kanbanguide] ### Operating model, ceremonies and governance Scrum prescribes five events inside a fixed-length Sprint: the Sprint itself, Sprint Planning (at most eight hours for a one-month Sprint), the 15-minute Daily Scrum, the Sprint Review (at most four hours) and the Retrospective (at most three hours); "For shorter Sprints, the event is usually shorter".[^scrumguide] Kanban prescribes no meetings; the Kanban Method calls recurring reviews "cadences" and expects them to grow with maturity.[^kanbanmethod] ::: figure One Scrum Sprint as an inspect-and-adapt loop ```mermaid flowchart TB PB["Product Backlog (ordered by Product Owner)"]:::neutral --> SP["Sprint Planning: why, what, how"]:::core SP --> SB["Sprint Backlog + Sprint Goal"]:::core SB --> DS["Daily Scrum, 15 min: inspect progress to goal"]:::core DS -->|"each working day"| SB SB --> INC["Increment that meets the Definition of Done"]:::core INC --> SR["Sprint Review: inspect outcome with stakeholders"]:::decision SR -->|"adapt"| PB SR --> RE["Retrospective: plan one improvement"]:::decision RE -->|"next Sprint starts at once"| SP classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 ``` Text equivalent: The Product Owner orders the Product Backlog. Sprint Planning answers why the Sprint is valuable, what can be done and how, producing a Sprint Backlog with a Sprint Goal. A 15-minute Daily Scrum each working day inspects progress toward the goal and adjusts the Sprint Backlog. Work produces an Increment that meets the Definition of Done. The Sprint Review inspects the outcome with stakeholders and feeds changes back into the Product Backlog; the Retrospective plans an improvement, and the next Sprint starts immediately with planning. ::: Two details are often missed: the Sprint Review "should never be considered a gate to releasing value", and the retrospective's "most impactful improvements are addressed as soon as possible".[^scrumguide] **Team-level governance** is small and explicit: the team changes policies and records the date; items older than the SLE are swarmed, then escalated; "expedite" has named criteria, one at a time; stakeholders read the board and the forecast, not a report. ## Architecture and workflow ### Reference architecture: the team's flow system For a non-technical subject the "architecture" is the structure of the work system: where work enters, where the team commits, which states it passes and where it leaves. Get it right and every metric has a clear meaning; get it wrong and "lead time" describes different spans in different meetings. ::: figure Where each time metric starts and stops ```mermaid flowchart TB subgraph PTS["Points on a work item"] direction TB R["1. Request created"]:::neutral --> C["2. Commitment point: team commits"]:::decision C --> S["3. Work started (pulled into progress)"]:::core S --> F["4. Finished: meets Definition of Done"]:::core F --> D["5. Delivered to requester or released"]:::core end subgraph SP["Spans: from point to point"] direction TB K1["Lead time on this page: 1 to 5"]:::neutral ~~~ K2["Kanban Method lead time: 2 to completion (4 or 5, per your delivery point)"]:::neutral K2 ~~~ K3["Kanban Guide cycle time: 3 to 4"]:::neutral K3 ~~~ K4["DORA change lead time: a commit made during 3 to production at 5; code only"]:::risk end PTS ~~~ SP classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 ``` Text equivalent: A work item passes five points: (1) request created, (2) commitment point, (3) work started, (4) finished to the Definition of Done, (5) delivered. The group below names both ends of each span: this page's lead time runs 1 to 5; Kanban Method lead time runs from 2 to completion, which is 4 or 5 depending on where your delivery point sits; Kanban Guide cycle time runs 3 to 4; DORA's change lead time starts at a commit made during step 3 and stops at production (5), for code changes only. ::: | Metric name | Starts | Stops | Defined by | |---|---|---|---| | Lead time | Request created | Delivered | This page | | Lead time | Commitment point | Completion | Kanban Method[^kanbanmethod] | | Cycle time | Started | Finished | Kanban Guide[^kanbanguide] | | Lead / cycle time | Created / "In Progress" | "Completed" state | Azure Boards[^azure] | | Change lead time | Commit | Deployed in production | DORA[^doralead] | **Design rules.** Put the commitment point where the team genuinely accepts the item. Keep one "finished" point per work item type, tied to the DoD. Model only states where work waits or changes hands. Give interrupts their own lane and WIP limit. ### End-to-end workflow The happy path is short: arrive, be ordered, be pulled when capacity frees up, finish to the DoD, deliver. The value of an explicit workflow lies in its exception paths. ::: figure Flow of one work item with its exception paths ```mermaid flowchart TB A["Request arrives"]:::neutral --> T{"Triage: which class of service?"}:::decision T -->|"expedite (named criteria)"| X["Expedite lane, WIP 1"]:::risk T -->|"standard"| B["Ordered backlog"]:::neutral B --> P{"WIP below limit?"}:::decision P -->|"no"| W["Wait: swarm on open items"]:::neutral W --> P P -->|"yes"| IP["In progress"]:::core X --> IP IP --> BL{"Blocked or older than SLE?"}:::decision BL -->|"yes"| E["Swarm, then escalate to delivery lead"]:::risk E --> IP BL -->|"no"| DOD{"Meets Definition of Done?"}:::decision DOD -->|"no"| IP DOD -->|"yes"| DL["Delivered; dates recorded"]:::core DL --> M["Flow review and retrospective"]:::core classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 ``` Text equivalent: A request is triaged by class of service. Expedite items, which must meet named criteria, use a lane limited to one item and go straight into progress; standard items join the ordered backlog. When WIP is at the limit the team swarms on open items instead of starting; below the limit, the next item is pulled. Blocked items or items older than the SLE trigger a swarm and then an escalation. Items that fail the Definition of Done stay in progress; items that meet it are delivered, their dates recorded for the flow review and the retrospective. ::: ## Practices, frameworks and tools ### Core practices and playbooks | Practice | Trigger | Owner | Verification | |---|---|---|---| | Limit WIP | Always; review monthly | Team | Days over limit; cycle-time trend | | Definition of Done | At start; after escaped defects | Team | Rework found after "done" | | Aging review | Daily | Delivery lead | Items older than the SLE | | Replenishment | Weekly or when Ready runs low | Product owner | Team never idles for lack of ordered work | | Retrospective with one experiment | Each Sprint or fortnight | Facilitator | Experiment closed with evidence | | Interrupt protection | Unplanned work keeps breaking plans | Engineering manager | Planned throughput stabilises | #### Playbook: setting and holding WIP limits 1. Count what is in progress today, per state; it is usually more than anyone thinks. 2. Set limits near the number of people or pairs in each state; DORA's example is four pairs, four cards "in development", and it asks you to account for "production support, meeting time and technical debt".[^dorawip] 3. When a column is full, do not start; help finish or unblock items further right. 4. When people are idle, **do not raise the limit**: "Don't relax your WIP limits when people are idle. Instead, those people should be helping in other parts of the value stream".[^dorawip] 5. When limits are easy to keep, lower them: "If your WIP limits are easy to achieve, reduce them."[^dorawip] Tools may only warn — Jira's column constraints "cause a warning to show" when exceeded[^jira] — so the limit is a team agreement, not a software feature. #### Playbook: a Definition of Done that works The DoD is "a formal description of the state of the Increment when it meets the quality measures required for the product"; an item that misses it "cannot be released or even presented at the Sprint Review", and teams sharing a product "must mutually define and comply with the same Definition of Done".[^scrumguide] Write verifiable lines, keep only what every item needs, and tighten it after each escaped defect it would have caught; Kanban teams use an exit policy on the last state. #### Playbook: retrospectives that change something Use the five phases of Derby, Larsen and Horowitz — set the stage, gather data, generate insights, decide what to do, close[^retros] — and open, if it suits the team, with Norm Kerth's Prime Directive: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."[^primedirective] Bring flow data into "gather data". End with **one** experiment that has a hypothesis, owner, measure and review date ([template](#templates)). #### Playbook: protecting an operations team from interrupts Google's SRE book estimates that a 20-minute interruption realistically costs "a couple hours of truly productive work", recommends "polarized time", and says a person "should never be expected to be on-call and also make progress on projects".[^sre-interrupts] On a board: an interrupt lane with its own WIP limit; every interrupt logged; one or two people rotated onto it weekly with no planned work, the rotation sized from a month of data; and repeated interrupt types fed into the improvement backlog (automate, document or push back to the source). ### Methods and frameworks: Scrum, Kanban and scaling **Scrum** is "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems", and it "exists only in its entirety and functions well as a container for other techniques".[^scrumguide] Many familiar "Scrum" practices are not in the Guide: | In the Scrum Guide (required) | Common additions (optional, not in the Guide) | |---|---| | Three accountabilities; Sprints of one month or less; five events | Story points and velocity | | Product Backlog, Sprint Backlog, Increment | "Definition of Ready" (the Guide only says items doable in one Sprint are "deemed ready for selection") | | Product Goal, Sprint Goal, Definition of Done | Burn-down charts (mentioned only as forecasting aids that "do not replace the importance of empiricism") | **Kanban** has two documented flavours: the **Kanban Guide** (Coleman and Vacanti, May 2025), with three practices and four mandatory metrics,[^kanbanguide] and the **Kanban Method** (Kanban University), which adds change principles ("Start with what you do now"), six general practices, classes of service and commitment-point lead time.[^kanbanmethod] The Guide says that "Many existing value-oriented approaches" share Kanban's theory and that Kanban "can and should be used to augment those delivery techniques".[^kanbanguide] It does not name Scrum; reading it as support for Kanban inside Scrum is this page's inference. **Scaling (high level).** Two of several frameworks make opposite bets; others, such as Nexus and Scrum@Scale,[^scrumatscale] are not covered here: - **LeSS** is "Scrum applied to many teams working together on one product": one Product Owner, one Product Backlog and one Sprint for two to eight feature teams (eight being an empirical limit, not a rule), and LeSS Huge beyond eight.[^less][^lesshuge] The bet: keep Scrum minimal and remove organisational layers. - **SAFe** groups teams into an Agile Release Train, "a long-lived team of Agile teams", "generally made up of 50 -125 people", with roles such as the Release Train Engineer and events such as PI (Planning Interval)[^safeinterval] Planning, "typically a 2-day event for the entire ART that takes place every 8-12 weeks".[^safeart][^safepi] As of October 2026 its site presents "Core SAFe" and an "AI-Native SAFe" variant.[^safehome] The bet: add explicit roles, events and portfolio layers. Both assume team-level flow already works. Portfolio funding (SAFe's Lean Portfolio Management included) is on [PortfolioOps](../portfolioops/). ### Tooling landscape Tools hold the board and timestamps; they do not create flow. Choose by the data they keep, and check what a tool actually measures before publishing its numbers. | Tool category | Examples (as of October 2026) | Selection criteria | Watch-outs | |---|---|---|---| | Physical or simple board | Whiteboard, spreadsheet | Visible to everyone | Dates recorded by hand | | Work-tracking systems | Jira, Azure Boards, GitHub Projects | State-change history; export or API; WIP display | Lead/cycle time defined differently per tool[^azure] | | Built-in charts | Jira Control Chart; Azure Boards cumulative flow diagram (CFD) and lead/cycle-time widgets; GitHub Projects burn-up[^github] | Percentiles, not only averages | Jira's control chart shows average cycle time and a rolling average;[^jira] averages hide the tail | | Analysis and forecasting | A script over an export ([Lab 2](#lab-2-intermediate-compute-flow-metrics-from-an-export)) | Reproducible, version-controlled | Bad timestamps in, bad forecast out | ### Automation and AI Automate the boring parts: timestamps on state changes, an alert when an item passes the SLE, a weekly forecast from the export, a reminder when an experiment is due for review. Language models can draft retrospective summaries or suggest how to split an item; the optional *Scrum Guide Expansion Pack* (not part of the Scrum Guide) includes an "AI and Scrum" document.[^sgexp] Keep people on commitments, customer-facing forecasts and anything said in a retrospective, and do not send retrospective notes to external services without the team's agreement. ## AgileOps in practice ### Reference implementation: a Definition of Workflow as a file **Context (illustrative scenario).** A six-person infrastructure team serves internal product teams with requests (access, environments, DNS), changes, defects and its own improvements; roughly a third of the work is unplanned. It runs Kanban and keeps its Definition of Workflow in version control, so policy changes are reviewed and dated like code. _Example status: syntax-checked YAML, not executed (it is a team agreement, read by people and by the Lab 2 script's conventions)._ ```yaml # definition-of-workflow.yaml — infrastructure team (illustrative) team: infra-platform version: 2026-09-14 work_item_types: [request, change, defect, improvement] commitment_point: "Ready" # team has accepted the item started_point: "In progress" # cycle time starts here finished_point: "Done" # meets the Definition of Done delivered_point: "Delivered" # requester confirmed or change live states: - {name: Ready, wip_limit: 6} - {name: In progress, wip_limit: 4} - {name: Review, wip_limit: 2} - {name: Done} lanes: - {name: Interrupts, wip_limit: 2, staffed_by: "weekly rotation (2 people)"} - {name: Planned, wip_limit: 4} classes_of_service: expedite: criteria: ["production outage", "security fix with a deadline"] wip_limit: 1 may_exceed_lane_limits: true fixed_date: {criteria: ["external deadline in writing"]} standard: {order: "backlog order set by the requester lead"} service_level_expectation: {percent: 85, days: 9, basis: "last 90 days of cycle time"} definition_of_done: - "peer-reviewed change or second-person check" - "applied via pipeline or runbook, not by hand" - "monitoring or alert updated if behaviour changed" - "runbook or docs updated; requester notified" policies: pull: "pull the top Ready item only when a lane is below its WIP limit" aging: "item older than the SLE: swarm at next daily check, then escalate" blocked: "mark blocked with reason and date; blocked items still count as WIP" cadences: daily_flow_check: "15 min, walk the board right to left" replenishment: "weekly, requester lead orders Ready" retrospective: "fortnightly, one experiment out" flow_review: "monthly, metrics from Lab 2 script" ``` Worth copying: blocked items **still count as WIP**; expedite has **named criteria and a limit of one**; the SLE states its basis. ### Hands-on labs No account, cost or risk. Labs 2 and 3 were executed on 2026-10-23 with Python 3.8.10; outputs are pasted from that run. #### Lab 1 (beginner): write your team's Definition of Workflow **Prerequisites:** a team you know, 60–90 minutes, a document or sticky notes. 1. List every kind of work done last month, including chat requests and incidents; group them into 3–5 work item types. 2. Mark where the team commits, starts, finishes (DoD) and delivers. 3. Draw the states between start and finish; delete any state where work neither waits nor changes hands. 4. Count today's items per state and set a WIP limit near the number of people working there. 5. Write expedite criteria and a 3–6 line DoD; fill in the [working-agreement template](#templates) or the YAML above. **Expected output:** one page with types, the four points, states, limits, expedite criteria and DoD. **Validation:** a newcomer can say for any item whether it counts as WIP and whether it is done. **Troubleshooting:** more than eight states usually means you mapped tasks; "we cannot limit WIP" usually means interrupts are not on the board yet. **Teardown:** none; revisit at the next retrospective. #### Lab 2 (intermediate): compute flow metrics from an export **Objective:** percentiles, throughput, WIP, work item age, an SLE and a Little's Law check from a CSV export. **Prerequisites:** Python 3.8 or later, no packages. The data are invented. The export, like many, records no delivery date, so the script reports *request-to-finish* time; add a `delivered` column to compute this page's lead time (request to delivery). Save this as `items.csv` (35 work items of the illustrative infrastructure team; an empty `finished` means still open): ```csv id,type,requested,started,finished OPS-101,request,2026-07-27,2026-08-03,2026-08-05 OPS-102,request,2026-07-28,2026-08-03,2026-08-04 OPS-103,change,2026-07-20,2026-08-04,2026-08-12 OPS-104,request,2026-08-03,2026-08-04,2026-08-06 OPS-105,defect,2026-08-04,2026-08-05,2026-08-05 OPS-106,change,2026-07-30,2026-08-06,2026-08-14 OPS-107,request,2026-08-05,2026-08-07,2026-08-10 OPS-108,request,2026-08-06,2026-08-10,2026-08-11 OPS-109,improvement,2026-07-15,2026-08-10,2026-08-21 OPS-110,request,2026-08-10,2026-08-11,2026-08-13 OPS-111,defect,2026-08-11,2026-08-12,2026-08-12 OPS-112,change,2026-08-03,2026-08-13,2026-08-19 OPS-113,request,2026-08-12,2026-08-14,2026-08-17 OPS-114,request,2026-08-13,2026-08-17,2026-08-18 OPS-115,change,2026-08-10,2026-08-17,2026-08-25 OPS-116,request,2026-08-17,2026-08-18,2026-08-20 OPS-117,defect,2026-08-18,2026-08-19,2026-08-20 OPS-118,request,2026-08-19,2026-08-20,2026-08-24 OPS-119,improvement,2026-08-01,2026-08-21,2026-09-03 OPS-120,request,2026-08-21,2026-08-24,2026-08-25 OPS-121,change,2026-08-17,2026-08-25,2026-08-28 OPS-122,request,2026-08-24,2026-08-26,2026-08-27 OPS-123,request,2026-08-25,2026-08-27,2026-08-31 OPS-124,defect,2026-08-27,2026-08-28,2026-08-28 OPS-125,change,2026-08-20,2026-08-31,2026-09-08 OPS-126,request,2026-08-28,2026-09-01,2026-09-02 OPS-127,request,2026-08-31,2026-09-02,2026-09-04 OPS-128,change,2026-08-26,2026-09-03,2026-09-09 OPS-129,request,2026-09-02,2026-09-07,2026-09-08 OPS-130,request,2026-09-03,2026-09-08,2026-09-10 OPS-131,improvement,2026-08-10,2026-08-24, OPS-132,change,2026-09-01,2026-09-07, OPS-133,request,2026-09-08,2026-09-09, OPS-134,request,2026-09-09,2026-09-10, OPS-135,defect,2026-09-10,2026-09-11, ``` Save this as `flow_metrics.py`: _Example status: verified by execution (Python 3.8.10, 2026-10-23), standard library only._ ```python """Flow metrics from a work-item export (standard library only). Usage: python3 flow_metrics.py items.csv 2026-09-11 CSV columns: id,type,requested,started,finished (finished empty = still open). Conventions (this page's choice): days are calendar days counted inclusively, so an item started and finished on the same day has a cycle time of 1 day; percentiles use the nearest-rank method. """ import csv import math import random import sys from collections import Counter from datetime import date, timedelta def days(a, b): return (b - a).days + 1 # inclusive: same day = 1 def pct(values, p): s = sorted(values) return s[max(0, math.ceil(p / 100 * len(s)) - 1)] def load(path): rows = [] with open(path, newline="") as f: for r in csv.DictReader(f): for k in ("requested", "started", "finished"): r[k] = date.fromisoformat(r[k]) if r[k] else None if r["started"] is None: continue # not started yet: not WIP, no cycle time if r["finished"] and r["finished"] < r["started"]: raise ValueError(f"{r['id']}: finished before started") rows.append(r) return rows def main(path, asof): items = load(path) done = [r for r in items if r["finished"] and r["finished"] <= asof] wip = [r for r in items if not r["finished"] or r["finished"] > asof] first = min(r["started"] for r in items) span = (asof - first).days + 1 cycle = [days(r["started"], r["finished"]) for r in done] # The export has no delivery date, so this is request-to-finish time, # not this page's lead time (request to delivery). lead = [days(r["requested"], r["finished"]) for r in done] print(f"window {first} .. {asof} ({span} days); finished {len(done)}") print(f"cycle time days: median {pct(cycle, 50)}, 85th {pct(cycle, 85)}, " f"max {max(cycle)}") print(f"request-to-finish days: median {pct(lead, 50)}, " f"85th {pct(lead, 85)}, max {max(lead)}") weeks = Counter((r["finished"] - first).days // 7 for r in done) n_weeks = math.ceil(span / 7) print("throughput per week:", [weeks.get(w, 0) for w in range(n_weeks)], "(last week partial)" if span % 7 else "") # Average WIP: count items in progress at the end of each day in the window. daily_wip = [] for d in range(span): day = first + timedelta(days=d) daily_wip.append(sum(1 for r in items if r["started"] <= day and (not r["finished"] or r["finished"] > day))) avg_wip = sum(daily_wip) / span rate = len(done) / span print(f"average WIP {avg_wip:.2f}; throughput {rate:.3f} items/day") # Little's Law, naive: finished items only. Inclusive day counts add one # day per item, so use (cycle - 1) as time in system. w = sum(c - 1 for c in cycle) / len(cycle) print(f"Little naive: {rate:.3f} x {w:.2f} = {rate * w:.2f} " f"(measured WIP {avg_wip:.2f})") # Little's Law over a finite window: arrivals x time each spent in window. lam = len(items) / span w_all = sum(daily_wip) / len(items) print(f"Little window: {lam:.3f} x {w_all:.2f} = {lam * w_all:.2f}") sle = pct(cycle, 85) print(f"SLE: 85% of items finish within {sle} days of starting") for r in sorted(wip, key=lambda r: r["started"]): age = days(r["started"], asof) flag = " <-- older than SLE" if age > sle else "" print(f" open {r['id']:8} {r['type']:12} age {age:>2} days{flag}") # Monte Carlo: resample daily throughput from the last 28 days. recent = [asof - timedelta(days=d) for d in range(28)] per_day = Counter(r["finished"] for r in done) sample = [per_day.get(d, 0) for d in recent] rng = random.Random(42) trials = 10000 in_14 = sorted(sum(rng.choice(sample) for _ in range(14)) for _ in range(trials)) print(f"next 14 days: 85% chance of finishing at least " f"{in_14[int(0.15 * trials)]} items") target, need = 10, [] for _ in range(trials): n = d = 0 while n < target: d += 1 n += rng.choice(sample) need.append(d) print(f"{target} more items: 85% chance within {pct(need, 85)} days " f"(by {asof + timedelta(days=pct(need, 85))})") if __name__ == "__main__": main(sys.argv[1], date.fromisoformat(sys.argv[2])) ``` Run it: ```bash python3 flow_metrics.py items.csv 2026-09-11 ``` **Expected output** (verbatim from the 2026-10-23 run): ```text window 2026-08-03 .. 2026-09-11 (40 days); finished 30 cycle time days: median 3, 85th 9, max 14 request-to-finish days: median 6, 85th 17, max 38 throughput per week: [4, 6, 6, 6, 4, 4] (last week partial) average WIP 3.38; throughput 0.750 items/day Little naive: 0.750 x 3.50 = 2.62 (measured WIP 3.38) Little window: 0.875 x 3.86 = 3.38 SLE: 85% of items finish within 9 days of starting open OPS-131 improvement age 19 days <-- older than SLE open OPS-132 change age 5 days open OPS-133 request age 3 days open OPS-134 request age 2 days open OPS-135 defect age 1 days next 14 days: 85% chance of finishing at least 7 items 10 more items: 85% chance within 18 days (by 2026-09-29) ``` **Validation:** the 30 cycle times sorted are 1 (×3), 2 (×8), 3 (×6), 4 (×3), 5 (×2), 7 (×2), 9 (×4), 12, 14; by nearest rank the median is the 15th value (3) and the 85th percentile the 26th (9). OPS-131, started 24 August, is 19 days old on 11 September. **Troubleshooting:** `finished before started` or `Invalid isoformat string` means a bad row; reopened items need a policy (new item or reset dates) before you trust cycle time. **Teardown:** delete the two files. **Reading the result.** The instructive line is the *naive* check: finished items only give 2.62 against a measured average WIP of 3.38. The finite-window line matches by construction — counting every item's days inside the window is an exact accounting identity, the form Little's paper calls LL.2[^little2011] — so it confirms the bookkeeping, not the law. The gap comes from the five open items (their 30 item-days add 0.75 of the 0.76 gap), mostly OPS-131: unfinished work never appears in a cycle-time average, which is why **work item age** is the metric to watch daily. #### Lab 3 (advanced): forecast a commitment and design a WIP experiment **Prerequisites:** Lab 2 completed. 1. Read the last two lines of the Lab 2 output. The script resamples the last 28 days of daily throughput 10,000 times: 85% chance of **at least 7 items** in the next 14 days, and of **10 more items within 18 days** (by 29 September). 2. Change `target, need = 10, []` to `target, need = 20, []` and run again. 3. Set the target back to 10, change `range(28)` to `range(14)` and run again. A shorter history reacts faster but is noisier. 4. Write an experiment card (template in the [Toolkit](#templates)): for example, "Lower the In progress limit from 4 to 3 for four weeks; expect the 85th-percentile cycle time to fall from 9 days without throughput falling below 4 items a week." 5. After four weeks, rerun Lab 2 and close the card with the evidence. **Expected output** (executed 2026-10-23): step 2 prints `20 more items: 85% chance within 34 days (by 2026-10-15)`; step 3 prints `at least 6 items` and `10 more items: 85% chance within 22 days (by 2026-10-03)` — the recent fortnight was slower; step 4 yields one card. **Validation:** a stakeholder can read the forecast sentence without statistics. **Troubleshooting:** a holiday fortnight in the sample makes the forecast pessimistic; exclude it explicitly or say so. **Teardown:** restore the two lines. ::: caution What the forecast assumes Resampling assumes the coming weeks resemble the sampled ones: same team, same mix of work, similar item sizes ([judgement call](#a-judgement-call-which-forecast-do-you-give-the-director)). Publish the date **with** its probability and update it weekly. ::: ### Use cases and scenarios #### Case 1: an infrastructure team drowning in interrupts (illustrative) **Problem:** a five-person network team commits to two-week sprints and misses every one; half its hours go to unplanned requests. **Method:** Kanban with an interrupt lane (limit 2) staffed by a weekly two-person rotation, following the SRE book's polarized time;[^sre-interrupts] every interrupt logged; fortnightly retrospective. **Trade-offs:** two people off planned work each week; the sprint "commitment" becomes an SLE and a forecast. **Success criteria:** planned throughput stable for six weeks; 85% of requests inside the SLE; the top interrupt type automated away. **Pitfall:** the rotation takes planned work "because it's quiet". #### Case 2: a product team whose "done" is not done (illustrative) **Problem:** high velocity, then a week of fixes after every release. **Method:** a DoD with automated tests, production-like deployment and monitoring; stop counting items that miss it; split items. **Trade-offs:** velocity drops for a few Sprints, which leadership must accept in advance. **Success criteria:** fewer post-release defects; Sprint Goals met more often; 85th-percentile cycle time falling. **Pitfall:** a DoD without the technical practices to meet it, the gap Fowler calls "Flaccid Scrum".[^fowler2009] #### Case 3: five teams, one product (illustrative) **Problem:** five component teams; most features need three of them; integration slips. **Method:** make each team's flow visible, then choose a bet: LeSS-style feature teams on one Product Backlog,[^less] or a SAFe-style train with PI Planning.[^safeart] **Trade-offs (editorial judgement):** LeSS asks for feature teams and fewer layers; SAFe asks for new roles, events and training and groups teams into trains. Which change costs more depends on the organisation. **Success criteria:** cross-team feature lead time and dependencies per feature falling. **Pitfall:** buying a framework to avoid fixing component boundaries. #### Case 4: copying a famous model (sourced, secondary) Spotify's "squad" model, described in a whitepaper by Anders Ivarsson and Henrik Kniberg, was widely copied. Jeremiah Lee, a former Spotify employee, wrote in 2020 that it "was only ever aspirational and never fully implemented", quoting Joakim Sundén, an agile coach there from 2011 to 2017: "Even at the time we wrote it, we weren't doing it. It was part ambition, part approximation."[^spotify] One person's account with second-hand quotes — but the lesson holds: copy the habit of experimenting, not the org chart. ## Measuring, governing and paying for the system ### Metrics and KPIs Measure the **system** with a few metrics whose start and stop points are written down. The Kanban Guide's four are the core;[^kanbanguide] the others answer specific questions. | Metric | Definition / formula | Pitfall | Cadence | |---|---|---|---| | WIP | Items started but not finished, counted at a fixed time daily | Blocked items left out | Daily | | Work item age | Today − start date, for open items | Ignored because it is not "finished" data | Daily | | Throughput | Items finished per day or week (a count, not points) | Mixing tiny and huge items silently | Weekly | | Cycle time | Finish − start; report median and 85th percentile | Averages hide the tail | Weekly | | Lead time | Delivered − requested (name your points) | Confused with DORA's change lead time[^doralead] | Monthly | | SLE hit rate | Items within the SLE ÷ items finished | Moving the SLE to flatter the rate | Monthly | | Experiment close rate | Experiments closed with evidence ÷ started | Counting actions, not results | Monthly | | Unplanned share | Interrupt items finished ÷ all finished | Interrupts not logged | Monthly | Age and WIP are **leading** indicators; cycle time, throughput and SLE hit rate **lag** — review only those and you learn of trouble a month late. **Reading a cumulative flow diagram (CFD).** Most tools draw one: the count of items in each state, stacked, day by day, with each coloured band one state.[^kanbanmethod][^azure] Three readings cover most uses. The *height* of the bands between "started" and "finished" on a day is that day's WIP. The *horizontal* distance from where a line rises to where the "finished" line reaches the same count approximates how long items spent in between (exact only when items finish in the order they started). The *shape* diagnoses: Microsoft's guidance reads a widening band (a bulge) as a problem in the step after it, and flat lines as stopped work or a board nobody updates.[^azure] #### Worked calculations (Lab 2 data) - **SLE:** 85th-percentile cycle time is 9 days, so "85% of items finish within 9 days of starting". - **SLE hit rate:** 28 of 30 items took 9 days or less, 93%. Flattering, because the SLE came from the same items; test next month's items against it. - **Throughput:** 30 items in 40 days = 0.75 a day, about 5 a week (weekly counts 4, 6, 6, 6, 4 and a partial 4). - **Little's Law:** 0.875 arrivals a day × 3.86 days = 3.38, the measured average WIP — over a fully counted window this holds by construction.[^little2011] The decision it supports: to cut time in the system by a third at the same arrival rate, cut average WIP by a third. - **Where time goes:** median request-to-finish time (6 days; the sample has no delivery dates) is twice median cycle time (3); the median wait *before* work starts is 4 days, and the longest waits (15, 20 and 26 days) were changes and improvements. Ordering and replenishment, not faster hands, fix that. ::: warning Vanity metrics and harmful uses The Agile Alliance glossary calls "individual velocity" meaningless and sees "no meaningful comparison of velocity 'between' different teams";[^velocity] Ron Jeffries, who says he may have invented story points, calls comparing teams on velocity "harmful".[^jeffries2019] Avoid utilisation, tickets closed per person and flow metrics in individual reviews: people game them and the data stop telling the truth. ::: ### Quality, security, privacy and compliance - **Quality** lives in the DoD, which stops "finishing" from meaning "shipping defects"; track rework next to cycle time. - **Confidentiality.** Boards hold incident and vulnerability details; restrict security items and link to the system of record. Pipeline security gates are on [DevSecOps](../devsecops/). - **People's privacy.** Flow data are timestamps about people's work. Report them per team; monitoring individuals can raise employment and data-protection questions that vary by jurisdiction — involve HR and legal advisers first. - **Compliance evidence.** Put required controls (review, approval, test evidence) into the DoD or the last state's exit policy so evidence is produced while finishing. Control design is on [ComplianceOps](../complianceops/); change approval on [ITOps](../itops/). ### Cost, capacity and sustainability **The cost of the cadence (worked example).** Scrum's timeboxes are maximums for a one-month Sprint.[^scrumguide] A seven-person team on two-week Sprints that chooses a 2-hour Planning, 1.5-hour Review, 1-hour Retrospective and a 15-minute Daily Scrum on each of the ten working days (2.5 hours) spends 7 hours per person per 80-hour Sprint: **8.75%** of capacity, 49 person-hours. It pays off only if the events replace other meetings, as the Guide intends.[^scrumguide] **Capacity, not utilisation.** Plan against what is left after interrupts, support and improvement work; DORA asks teams to account for "production support, meeting time and technical debt".[^dorawip] Full utilisation creates queues. **Sustainability.** The Manifesto's principle that sponsors, developers and users "should be able to maintain a constant pace indefinitely" is a capacity rule:[^principles] persistent overtime means WIP or scope is too high. Cost of delay across initiatives is on [PortfolioOps](../portfolioops/). ### Assurance of the operating model Ceremonies can run while the system stagnates. Close a loop from data to policy, and audit it. ::: figure The improvement loop from flow data to policy change ```mermaid flowchart TB D["Timestamps from the board"]:::neutral --> M["Flow metrics: WIP, age, cycle time, throughput"]:::core M --> R["Daily: aging items, swarm or escalate"]:::core M --> S["Retrospective: one experiment"]:::decision S --> P["Policy change: WIP limit, DoD, lanes"]:::core P --> B["Board and Definition of Workflow updated"]:::neutral B --> D S -.->|"experiment fails"| K["Revert policy; record learning"]:::risk K --> B classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 ``` Text equivalent: Board timestamps produce flow metrics (WIP, work item age, cycle time, throughput). Daily, aging items trigger a swarm or escalation. At the retrospective the metrics inform one experiment, which leads to a policy change (WIP limit, Definition of Done, lanes); the board and Definition of Workflow are updated, changing what the next cycle measures. A failed experiment is reverted and its learning recorded. ::: **Monthly signals:** complete timestamps; days over WIP limits; items older than the SLE; experiments closed with evidence. **Audit questions:** Is every interrupt on the board? Which policy did you last change, and what did the data show afterwards? ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause | Diagnosis | Remediation and prevention | |---|---|---|---| | Throughput flat, cycle time rising | WIP creeping up | Daily WIP against limits | Stop starting, swarm on oldest; hold limits | | Sprint Goal missed repeatedly | Interrupts or oversized items | Unplanned share; size spread | Interrupt rotation; split items | | Items reopened after "done" | Weak DoD | Reopens per item type | Tighten DoD after each escape | | Forecasts always wrong | Data gaps or changed work mix | Missing dates; mix by type | Automate timestamps; forecast per type | | Retro actions never happen | Too many actions, no owner | Experiment close rate | One experiment, owner, date | | Board green, customers unhappy | Long waits before commitment | Request-to-start wait | Replenish more often; report lead time | #### Worked runbook: aging work and falling throughput **Trigger** (illustrative): over three weeks weekly throughput falls from 6 to 3 and items older than the SLE rise from one to five. 1. **Stabilise (day 1).** Freeze new starts except expedite; for each item older than the SLE, ask what it needs and who can help. 2. **Diagnose (days 1–2).** Plot daily WIP per state against its limit: typically one reviewer for many authors, items blocked on another team, or a large item that never splits. 3. **Check interrupts.** A jump in unplanned share points to incidents or a new request source, not to "slow people". 4. **Remediate (week 1).** Swarm reviews; agree a second-reviewer policy; escalate external blocks with dates and impact; split the large item so part of it finishes this week. 5. **Restore (week 2).** Resume starts only when WIP is back at the limits; publish a revised forecast with its probability. 6. **Prevent and verify.** Take one experiment into the next retrospective; four weeks later, items older than the SLE should be at most one and throughput back in its band. **Do not** raise WIP limits to "get more done", hire into the bottleneck before measuring it, or hold a blame session — the Prime Directive exists for this moment.[^primedirective] ### Anti-patterns and myths - **Dark Scrum.** Jeffries: "Too often, at least in software, Scrum seems to oppress people"; it begins "when people who know their old job, but not their new Scrum job, begin to do the Scrum activities".[^jeffries2016] Signal: the Daily Scrum is a status report to a manager. Instead: it belongs to the Developers and the Sprint Goal.[^scrumguide] - **Flaccid Scrum.** Ceremonies without engineering practice: "progress is slow because the code base is a mess", since Scrum "deliberately omits any technical practices".[^fowler2009] Pair this page with [DevOps](../devops/). - **Velocity as a target or league table**, **relaxed WIP limits when people are idle** and **Sprints without interrupt capacity** — covered above.[^velocity][^dorawip][^sre-interrupts] - **Retrospective theatre:** the same complaints, long action lists, nothing closed. - **Tools without principles.** In 2010 one practitioner warned against implementing "the processes or tools without the principles in mind".[^mueller2010] - **Scaling first**, before any team has visible, limited WIP. - **Myth: "Kanban means no planning."** The Kanban Method describes regular meetings and reviews ("cadences") and policies for replenishing the board;[^kanbanmethod] it removes fixed iterations, not planning. - **Myth: "Agile means no documentation or no dates."** The Manifesto says "there is value in the items on the right".[^manifesto] Dates are fine; promises without probabilities are not. ## Deciding and adopting ### When to use and when not to use **Use these practices** for knowledge work with real uncertainty, where requests arrive faster than they can be finished, priorities shift within weeks and the people doing the work can change how they work: most software, infrastructure, data, design and operations teams. **Use them lightly or not at all when:** - **The work is one bounded project with stable scope and contractual milestones** — predictive or hybrid control may fit better ([ProjectOps](../projectops/)). - **You are in an incident** — that needs a command structure ([IncidentOps](../incidentops/)); bring follow-ups to the board after. - **One person works alone** — a personal list helps; events, roles and team metrics add little. - **Leadership wants a monitoring tool** — if the real goal is utilisation or individual velocity, the practices will be gamed. - **The constraint is elsewhere** — items finish fast but wait weeks for a release window or approval board: fix that first with [ReleaseOps](../releaseops/), [DevOps](../devops/) or [ITOps](../itops/). **Hidden responsibilities:** clean timestamps, good facilitation, defending WIP limits under pressure, and changing policies when the data say so. ### Decision framework The decision that matters most is not "agile or not" but **which cadence and flow controls fit how work arrives**. ::: figure Choosing a working method from how work arrives ```mermaid flowchart TB Q1{"Is it one bounded project with fixed scope and dates?"}:::decision Q1 -->|"yes"| PJ["Predictive or hybrid control: ProjectOps page"]:::neutral Q1 -->|"no"| Q2{"How does work arrive?"}:::decision Q2 -->|"planned in batches, priorities stable for 1 to 4 weeks"| SC["Scrum; add Kanban flow metrics"]:::core Q2 -->|"unpredictable, varied sizes, fast response needed"| KB["Kanban with SLE and classes of service"]:::core Q2 -->|"both, and interrupts break plans"| HY["Kanban or Scrum plus a protected interrupt rotation"]:::core SC --> Q3{"More than one team on one product?"}:::decision KB --> Q3 HY --> Q3 Q3 -->|"no"| T["Run and improve at team level"]:::core Q3 -->|"yes"| Q4{"Does each team already have visible, limited WIP?"}:::decision Q4 -->|"no"| FX["Fix team-level flow first"]:::risk Q4 -->|"yes"| SF["Choose a scaling bet: LeSS-style or SAFe-style"]:::decision classDef core fill:#e8f3f2,stroke:#16756f,color:#122029 classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029 classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029 classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029 ``` Text equivalent: If the work is one bounded project with fixed scope and dates, use predictive or hybrid control (ProjectOps page). Otherwise ask how work arrives: planned in batches with priorities stable for one to four weeks suits Scrum plus flow metrics; unpredictable, varied work needing fast response suits Kanban with an SLE and classes of service; a mix where interrupts break plans needs either method plus a protected interrupt rotation. Then, if more than one team works on one product, check that each team has visible, limited WIP; if not, fix team-level flow first; if so, choose a LeSS-style or SAFe-style scaling bet. ::: | Question | Points toward Scrum | Points toward Kanban | |---|---|---| | Share of unplanned work | Low | Medium to high | | Value of a fixed planning rhythm with stakeholders | High | Low or met by replenishment | | Item sizes | Can be split to fit a Sprint | Vary widely | | Need for customer-facing response times | Low | High (use an SLE) | These are leanings, not a score. ### Maturity model **This is the Atlas's model**, a self-assessment aid; no standard defines AgileOps levels. Teams can regress, for example after a reorganisation or a tool migration; reassess after either. | Level | Observable behaviour | Exit criterion to next level | |---|---|---| | 0 Ad hoc | Work tracked in heads, chat and email | Every current item on one board | | 1 Visible | One board; interrupts logged | Start and finish dates on 90% of items | | 2 Limited | WIP limits held; written DoD; expedite criteria | Two months of clean data; SLE computed | | 3 Predictable | SLE published; forecasts with probabilities; SLE hit rate tracked on new items | Experiments run and closed monthly | | 4 Improving | Policies change from evidence; cross-team flow visible | Sustain; extend upstream and downstream | ### Adoption roadmap: 30/60/90 days | Window | Actions | Milestone | |---|---|---| | Days 1–30 | Lab 1 workshop; all work on one board, interrupts included; dates recorded; first DoD; first retrospective with one experiment | All work visible; dates on 90% of new items | | Days 31–60 | WIP limits held; interrupt lane or rotation; weekly replenishment; daily aging check; first Lab 2 run | Days over limit falling; first SLE | | Days 61–90 | Publish the SLE and a range forecast; monthly flow review; two more experiments; revisit Scrum versus Kanban | Forecast with probability published; one policy changed from evidence | **Quick wins:** interrupts on the board; an aging check in the daily meeting. **Dependencies:** state-change dates, and a manager who defends WIP limits against "just one more". ## Toolkit ### Checklists #### Quick start - [ ] Every current work item, interrupts included, is on one board. - [ ] Commitment, start, finish and delivery points are written down. - [ ] A Definition of Done exists and is applied to every item. - [ ] Start and finish dates are recorded automatically or by habit. - [ ] The next retrospective will end with one experiment. #### Weekly flow review - [ ] Items older than the SLE named, each with an owner and next step. - [ ] Days over WIP limits explained. - [ ] Throughput compared with its recent band; unplanned share checked. - [ ] Forecast updated and shared with its probability. #### Retrospective and scaling preflight - [ ] Last experiment reviewed first, with data; nothing said is used in individual evaluations. - [ ] Before scaling: each team has visible work, held WIP limits and one shared DoD per product;[^scrumguide] the reason for the chosen framework and the alternative considered are written down. ### Templates #### One-page team working agreement ```text TEAM WORKING AGREEMENT version: YYYY-MM-DD Team / service: ____________ Requester lead: ____________ Work item types: ____________________________________________ Commitment point: ________ Start: ________ Finish (DoD): ________ Delivery point: ________ States and WIP limits: ______________________________________ Interrupt handling: lane limit __ ; rotation of __ people per week Expedite criteria (max 1 at a time): ________________________ Service level expectation: __% of items within __ days of start Cadences: daily __ min | replenishment ____ | retro ____ | review ____ Who may change this agreement: the team, recorded in the changelog ``` #### Definition of Done ```text DEFINITION OF DONE (applies to every item) version: YYYY-MM-DD [ ] Reviewed by a second person [ ] Automated checks pass (tests, lint, policy) [ ] Deployed or applied through the standard path, not by hand [ ] Monitoring, alerts or dashboards updated if behaviour changed [ ] User-facing or runbook documentation updated [ ] Requester informed; item linked to evidence Changed after escaped defect? Note the defect ID: ________ ``` #### Retrospective experiment card ```text EXPERIMENT opened: YYYY-MM-DD Problem observed (with data): _______________________________ Hypothesis: If we ______________, then ______________ will change Change to policy or practice: _______________________________ Measure and current value: ______________ Target: ___________ Owner: ____________ Review date: YYYY-MM-DD (2-6 weeks) Result (closed YYYY-MM-DD): kept / adjusted / reverted, because ____ ``` #### Operations intake form ```text REQUEST TO INFRA-PLATFORM Requester and team: ____________________ What outcome do you need? ____________________________________ Needed by (only if a real external date): YYYY-MM-DD, because ____ Type: [ ] access [ ] environment [ ] change [ ] defect [ ] other Is production down or a security deadline involved? [ ] yes [ ] no (yes = expedite criteria; on-call is paged, not this form) Smallest useful first step: __________________________________ ``` #### Monthly flow scorecard | Measure | This month | Last month | Note | |---|---|---|---| | Throughput (items) | | | Count, not points | | Cycle time median / 85th percentile (days) | | | | | SLE hit rate on new items | | | Against last month's SLE | | Items older than SLE at month end | | | | | Unplanned share | | | | | Experiments closed with evidence | | | | ### Deep comparisons | Aspect | Scrum (2020 Guide) | Kanban Guide (2025) | Kanban Method | SAFe | LeSS | |---|---|---|---|---|---| | Unit | One team, 10 or fewer | Any workflow | A service | Train of 50–125 people | 2–8 teams per product | | Cadence | Sprints of one month or less | None prescribed | Cadences grow with maturity | PI every 8–12 weeks | One shared Sprint | | Roles | PO, SM, Developers | None | Leadership at all levels | Many, incl. RTE | One PO; SM per 1–3 teams | | Metrics | None prescribed | WIP, throughput, age, cycle time | Lead time, delivery rate, WIP | Six flow metrics, incl. flow velocity and flow time[^safeflow] | Scrum's | | Change approach | Adopt the whole framework | Augment what exists | Start with what you do now | Not reviewed here | Deep structural change | Sources: the framework pages cited above, opened 2026-10-23.[^scrumguide][^kanbanguide][^kanbanmethod][^safeart][^safepi][^less] "Not reviewed here" marks a SAFe topic this page did not research. Mind the names: SAFe's Flow Velocity is "The number of backlog items completed in a given time" — a throughput count, not story-point velocity — and its Flow Time runs from when an item "enters the workflow to its release", yet another span to name.[^safeflow] ### FAQ **Is AgileOps a certification or a framework to adopt?** No. It is an informal label with several meanings. Adopt specific, documented practices for specific problems. **Is Kanban "agile"?** Kanban for knowledge work dates from 2006, after the Manifesto,[^kanbanguide][^history] and the Kanban Guide never uses the word agile. Its practices serve the Manifesto's principles; the label has no practical consequence. **Can an operations team use Scrum?** Yes, if most work can be planned for a Sprint and a rotation outside Sprint planning absorbs interrupts; the Guide lists "maintenance, operation" among the Scrum Team's responsibilities.[^scrumguide] With much unplanned work, Kanban usually fits better. **Story points or counting items?** Counting finished items forecasts well when items are split to similar sizes; points add a translation step and invite comparison. Neither Guide requires points.[^scrumguide][^kanbanguide] **Is our tool's "lead time" the same as DORA's?** Almost certainly not: DORA's runs from commit to production;[^doralead] Azure Boards' from item creation to completion.[^azure] DORA metrics are taught on [DevOps](../devops/). **Should we adopt SAFe?** Only if many teams must deliver one solution together, team-level flow already works and you accept its roles, events and training cost; compare with LeSS's lighter structure first.[^safeart][^less] ## Going further ### Advanced topics and emerging direction - **Forecasting across teams.** Dependencies break the independence that Monte Carlo resampling assumes; forecast a multi-team feature as one flow. - **Flow beyond the team.** The Kanban Guide now allows several Definitions of Workflow and "encourages establishing a DoW wherever the Kanban system members require connecting flow to value realization",[^kanbanguide] linking upstream discovery ([ProductOps](../productops/)) and downstream release ([ReleaseOps](../releaseops/)). - **AI-assisted teams.** The Expansion Pack's authors and Scaled Agile now publish AI-specific guidance (an "AI and Scrum" expansion; "AI-Native SAFe").[^sgexp][^safehome] That is guidance, not evidence of outcomes; measure any AI change like other experiments. ### Learning path | Stage | What to do | Output | |---|---|---| | 1-day primer (no prerequisites) | Read the Manifesto, its principles, the Scrum Guide and the Kanban Guide[^manifesto][^scrumguide][^kanbanguide] | One paragraph on each | | 1 week | Lab 1 with your team; Lab 2 on a real export | A DoW and first percentiles | | 30 days | Hold WIP limits; two retrospectives with experiments; a published forecast | Two closed experiment cards | | Advanced | Kanban Method (STATIK, classes of service);[^kanbanmethod] Little's paper;[^little2011] one scaling framework's own site | A design for a multi-team service | | Portfolio project | Take a team from maturity level 1 to 3 | A before-and-after case study | ## Wrap-up ### Executive recap and cheat sheet - **The label is ambiguous**; the practices are not. Use Scrum, Kanban, a DoD, WIP limits and retrospectives by name. - **Decide** the method from how work arrives; protect interrupt capacity in operations teams. - **Do daily:** walk the board right to left; act on items older than the SLE. - **Measure:** WIP, throughput, work item age, cycle time (median and 85th percentile), SLE hit rate; name the timestamps. - **Forecast:** ranges with probabilities from your own history; update weekly. - **Never:** compare velocity across teams, raise WIP limits because people are idle, or use flow data for individual ratings. - **Scale last**, after team-level flow works. - **Next actions:** run Lab 1 this week; record dates; hold one retrospective that ends with one experiment. ### A judgement call: which forecast do you give the director? **Situation (illustrative).** The Lab 2 team must migrate 20 services to a new platform; a director needs a date for a customer. Three numbers are on the table: - **Points plan:** 60 story points at an average velocity of 20 a fortnight — "six weeks". - **Monte Carlo on all history** (Lab 3 step 2): 85% chance within **34 days**, by 15 October. - **Monte Carlo on similar work** (target 20 on change items only: `grep -E '^id|,change,' items.csv > changes.csv`, then run the script on `changes.csv`): 85% chance within **136 days**, by 25 January 2027. Only five changes finished in the last 28 days. **Assumptions.** Migrations resemble past changes more than access requests; interrupts continue; the team does not grow. **Option A — 34 days.** Data-driven and earlier, so the director will like it. It is wrong: 17 of the 30 finished items are requests with a median cycle time of 3 days, while changes took 9. A forecast is only as good as the match between sampled and forecast work. **Option B — six weeks.** Familiar and between the extremes, but velocity "is not itself a budget or a forecast",[^velocity] the points were guessed before anyone migrated a service, and the plan ignores the interrupt lane. **Decision.** Commit to neither. Say: "Our evidence ranges from about five weeks to about four months. We will run the first three migrations in a dedicated lane with its own WIP limit and give you an 85% date in two weeks." Then forecast from the lane's own throughput — the Scrum Guide's rule that "Only what has already happened may be used for forward-looking decision making".[^scrumguide] **Why the attractive choice is wrong, and what stays uncertain.** Option A wins the meeting and loses the quarter. Even the lane forecast fails if later migrations differ from the first ones, which is why it is updated weekly. ### Learning objectives and mastery check You should now be able to **explain** the label's ambiguity, **design** a Definition of Workflow and DoD, **compute** flow metrics and an SLE, **choose** a method from how work arrives, and **evaluate** a forecast or scaling proposal. 1. Your tool reports "lead time 4 days"; DORA's lead time for the same team is 1 day. Is one wrong? ::: answer Show answer for question 1 Probably neither: DORA's runs from commit to production,[^doralead] a tool's may run from creation to completion.[^azure] Ask for the two timestamps before comparing. ::: 2. Three people are idle because Review is at its WIP limit. A manager proposes raising the limit. What do you do? ::: answer Show answer for question 2 Keep the limit; the idle people help review or remove the cause of slow reviews. DORA: do not relax WIP limits when people are idle; help elsewhere in the value stream.[^dorawip] ::: 3. Average WIP is 6 and items arrive at 1.5 a day. How long does an item spend in the system, and what if WIP rises to 9? ::: answer Show answer for question 3 By Little's Law W = L ÷ λ = 6 ÷ 1.5 = 4 days; at WIP 9, 6 days. More WIP at the same rate means longer waits.[^little2011] ::: 4. A team calls its "Definition of Ready" part of Scrum. Is it? ::: answer Show answer for question 4 No. The Guide only says items doable within one Sprint "are deemed ready for selection"; a Definition of Ready is an optional addition that can become a gate.[^scrumguide] ::: 5. An operations team misses every Sprint Goal; 40% of its work is unplanned. Name two remedies. ::: answer Show answer for question 5 Kanban with an interrupt lane and an SLE, or Scrum with an interrupt rotation excluded from Sprint planning (polarized time). Either way, log every interrupt and plan only the remaining capacity.[^sre-interrupts] ::: 6. Leadership wants to rank teams by velocity. What do you say? ::: answer Show answer for question 6 Velocity is not comparable between teams, and a Manifesto author calls comparing teams on it harmful.[^velocity][^jeffries2019] Compare each team's flow and outcomes with its own history. ::: ### Conclusion "AgileOps" is a label looking for a meaning; four have been published and none has won. The practices it gestures at, by contrast, are well documented and teachable: a manifesto of values, a short framework for working in Sprints, a short guide for managing flow, and a small piece of queueing theory that explains why finishing beats starting. Teams that adopt the vocabulary without those mechanics get ceremonies; teams that adopt the mechanics — visible work, limited WIP, one meaning of done, forecasts as ranges and one experiment at a time — get a system that improves itself, whatever they call it. Start with the board you already have, write down what "started" and "finished" mean, and let the data decide your next change. ## Sources and further reading All sources were opened on 2026-10-23; dates are the sources' own. Claim-level notes are in `research/agileops-ledger.md`. [^tt2022]: [Agile operations (AgileOps)](https://www.techtarget.com/searchitoperations/definition/Agile-operations-AgileOps) — Corinne Bernstein, TechTarget, 2022-02-17. Checked 2026-10-23. [^ttvs2022]: [DevOps vs. AgileOps: What's the difference?](https://www.techtarget.com/searchitoperations/tip/DevOps-vs-AgileOps-Whats-the-difference) — Will Kelly, TechTarget, 2022-08-10. Checked 2026-10-23. [^cisco2019]: [Principles of Agile Infrastructure](https://news-blogs.cisco.com/ciscoit/principles-of-agile-infrastructure) — Prateek Verma, Cisco Blogs (Inside Cisco IT), 2019-10-02. Checked 2026-10-23. [^mueller2010]: [Defining Agile Operations and DevOps](https://theagileadmin.com/2010/03/11/defining-agile-operations-and-devops/) — Ernest Mueller, the agile admin, 2010-03-11. Checked 2026-10-23. [^apress2022]: [Hands-On Guide to AgileOps: A Guide to Implementing Agile, DevOps, and SRE for Cloud Operations](https://doi.org/10.1007/978-1-4842-7505-4) — Navin Sabharwal, Raminder Rathore, Udita Agrawal, Apress, 2022; bibliographic details from the Crossref record (the publisher page could not be fetched automatically). Checked 2026-10-23. [^debois2008]: [Agile Infrastructure and Operations: How Infra-gile are You?](https://doi.org/10.1109/agile.2008.42) — Patrick Debois, Agile 2008 Conference, pp. 202–207, 2008; bibliographic details from the Crossref record (the IEEE page could not be fetched automatically). Checked 2026-10-23. [^manifesto]: [Manifesto for Agile Software Development](https://agilemanifesto.org/) — Beck, Beedle, van Bennekum et al., 2001. Checked 2026-10-23. [^principles]: [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html) — agilemanifesto.org, 2001. Checked 2026-10-23. [^history]: [History: The Agile Manifesto](https://agilemanifesto.org/history.html) — Jim Highsmith for the Agile Alliance, 2001. Checked 2026-10-23. [^scrumguide]: [The Scrum Guide](https://scrumguides.org/scrum-guide.html) — Ken Schwaber, Jeff Sutherland, November 2020. Checked 2026-10-23. [^sgexp]: [Scrum Guide Expansion Pack](https://scrumexpansion.org/) — Jeff Sutherland, John Coleman, Ralph Jocham; an optional companion to the 2020 Scrum Guide, not part of it (undated site). Checked 2026-10-23. [^kanbanguide]: [The Kanban Guide (v2025.5)](https://kanbanguides.org/english/) — John Coleman, Daniel Vacanti, updated 2025-05-01. Checked 2026-10-23. [^kanbanmethod]: [The Official Kanban Guide (Kanban Method)](https://kanban.university/kanban-guide/) — Kanban University, undated (© 2026). Checked 2026-10-23. [^little2011]: [Little's Law as Viewed on Its 50th Anniversary](https://doi.org/10.1287/opre.1110.0940) — John D. C. Little, *Operations Research* 59(3) 536–549, INFORMS, 2011. Checked 2026-10-23 (read via a university course copy). [^dorawip]: [Capabilities: Work in process limits](https://dora.dev/capabilities/wip-limits/) — DORA, undated. Checked 2026-10-23. [^doralead]: [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics/) — DORA, updated 2026-01-05. Checked 2026-10-23. [^azure]: [Cumulative flow guidance for lead time and cycle time](https://learn.microsoft.com/en-us/azure/devops/report/dashboards/cumulative-flow-cycle-lead-time-guidance?view=azure-devops) — Microsoft Learn, ms.date 2025-09-10, shown as "Last updated on" 2025-10-27. Checked 2026-10-23. [^jira]: [How to do kanban with Jira](https://www.atlassian.com/agile/tutorials/how-to-do-kanban-with-jira) — Atlassian, undated tutorial. Checked 2026-10-23. [^github]: [About insights for Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/viewing-insights-from-your-project/about-insights-for-projects) — GitHub Docs, undated. Checked 2026-10-23. [^less]: [Introduction to LeSS](https://less.works/less/framework/introduction) — Craig Larman, Bas Vodde, less.works, undated. Checked 2026-10-23. [^lesshuge]: [Scaling with LeSS Huge](https://less.works/less/less-huge) — less.works, undated. Checked 2026-10-23. [^safeart]: [Agile Release Train](https://framework.scaledagile.com/agile-release-train) — Scaled Agile, Inc., © 2010–2026. Checked 2026-10-23. [^safepi]: [PI Planning](https://framework.scaledagile.com/pi-planning) — Scaled Agile, Inc., © 2026. Checked 2026-10-23. [^safeinterval]: [Planning Interval (PI)](https://framework.scaledagile.com/planning-interval) — Scaled Agile, Inc., last updated 2025-02-25. Checked 2026-10-23. [^safeflow]: [Accelerating Flow with SAFe](https://framework.scaledagile.com/accelerating-flow-with-safe) — Scaled Agile, Inc., last updated 2025-03-12. Checked 2026-10-23. [^scrumatscale]: [The Official Scrum@Scale Guide](https://www.scrumatscale.com/scrum-at-scale-guide/) — Scrum Inc. (Jeff Sutherland), undated. Checked 2026-10-23. [^safehome]: [Scaled Agile Framework (home)](https://framework.scaledagile.com/) — Scaled Agile, Inc., as shown on 2026-10-23. Checked 2026-10-23. [^spotify]: [Spotify's Failed #SquadGoals](https://www.jeremiahlee.com/posts/failed-squad-goals/) — Jeremiah Lee, 2020-04-19. Checked 2026-10-23. [^sre-interrupts]: [Dealing with Interrupts](https://sre.google/sre-book/dealing-with-interrupts/) — Dave O'Connor, in *Site Reliability Engineering*, Google / O'Reilly, 2016. Checked 2026-10-23. [^fowler2009]: [Flaccid Scrum](https://martinfowler.com/bliki/FlaccidScrum.html) — Martin Fowler, 2009-01-29. Checked 2026-10-23. [^jeffries2016]: [Dark Scrum](https://ronjeffries.com/articles/016-09ff/defense/) — Ron Jeffries, 2016-09-08. Checked 2026-10-23. [^jeffries2019]: [Story Points Revisited](https://ronjeffries.com/articles/019-01ff/story-points/Index.html) — Ron Jeffries, 2019-05-23. Checked 2026-10-23. [^velocity]: [Velocity (glossary)](https://www.agilealliance.org/glossary/velocity/) — Agile Alliance, undated. Checked 2026-10-23. [^primedirective]: [The Prime Directive](https://retrospectivewiki.org/index.php?title=The_Prime_Directive) — Retrospective Wiki, quoting Norm Kerth, *Project Retrospectives: A Handbook for Team Review*. Checked 2026-10-23. [^retros]: [Agile Retrospectives, Second Edition](https://pragprog.com/titles/dlret2/agile-retrospectives-second-edition/) — Esther Derby, Diana Larsen, David Horowitz, Pragmatic Bookshelf, 2024. Checked 2026-10-23. **Changelog.** 2026-10-23, r0: first draft — term status confirmed as ambiguous (four published meanings), Blueprint v2 with 13 parts, six diagrams, three labs (two executed), evidence ledger created. No independent review yet. **Changelog.** 2026-10-23, r1: revised after independent fact check (`reviews/agileops-r1.md`) — Lab 2 now reports request-to-finish time (the sample has no delivery dates); RACI gives the team accountability for the DoD and WIP limits; Figure 3 names both ends of every span; Figure 1 fits phones; cumulative flow diagrams taught; SAFe flow metrics added; Little's Law wording, Expansion Pack status, acronyms and two unsourced generalisations corrected; Labs 2 and 3 re-executed (numbers unchanged). **Changelog.** 2026-10-23, post-score polish: "Planning Interval" footnoted to SAFe's own page; the Kanban Guide's multiple-DoW sentence quoted exactly; Azure footnote shows both page dates; judgement-call command made runnable (re-executed: 136 days); Figure 3 stacked top to bottom so the spans fit a phone column.