AgileOps

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”^[1] to “a highly localised agile mindset shift for infrastructure teams”.^[2] No foundation, standard or certification owns it, and one TechTarget article says plainly that it “has different definitions depending on who’s marketing what”.^[3]

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.

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^[4] — and Kanban adds the mechanics: an explicit workflow, controlled WIP and four flow metrics.^[5] 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.

• Not a standard or a certification. No body owns the label.
• Not DevOps. CI/CD and DORA metrics are on 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.

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.^[8] 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.^[9]
• 2006–2010. Kanban for knowledge work “mainly originated on a team at Corbis in 2006”;^[5] David Anderson’s 2010 book became the basis of the Kanban Method.^[10] The first Scrum Guide appeared in 2010.^[8]
• 2008–2010: agile meets operations. Patrick Debois presented “Agile Infrastructure and Operations: How Infra-gile are You?” at Agile 2008;^[11] by 2010 “Agile Operations” and “DevOps” were used interchangeably.^[7] “DevOps” won.
• 2019–2022: the one-word label appears in a Cisco blog, TechTarget and an Apress book, each with a different meaning.^[2][1][6]
• 2020–2025: the guides keep moving. The Scrum Guide is still the November 2020 edition;^[8] 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.^[12] The May 2025 Kanban Guide renamed “Kanban Measures” to “Flow Metrics” and deleted a reference to Kanban’s immutability.^[5]

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.^[14]

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

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”.^[15] 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”.^[4]

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”.^[8] The Kanban Guide defines no roles,^[5] and the Kanban Method encourages “acts of leadership at all levels”.^[10] Without Scrum, someone must still facilitate and order the work; name who.

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”.^[8] The Kanban Method says WIP limits “need to be agreed to by everyone actively involved”.^[10] The facilitator helps the team decide; it does not decide for it. In Scrum, only the Product Owner may cancel a Sprint.^[8]

• 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”.^[10] 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).
• 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.^[5]

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”.^[8] Kanban prescribes no meetings; the Kanban Method calls recurring reviews “cadences” and expects them to grow with maturity.^[10]

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

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”.^[8]

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.

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.

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

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.

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.

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

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”.^[18]
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”.^[18]
5. When limits are easy to keep, lower them: “If your WIP limits are easy to achieve, reduce them.”^[18]

Tools may only warn — Jira’s column constraints “cause a warning to show” when exceeded^[19] — so the limit is a team agreement, not a software feature.

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”.^[8] 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.

Use the five phases of Derby, Larsen and Horowitz — set the stage, gather data, generate insights, decide what to do, close^[20] — 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.”^[21] Bring flow data into “gather data”. End with one experiment that has a hypothesis, owner, measure and review date (template).

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”.^[22] 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).

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”.^[8] Many familiar “Scrum” practices are not in the Guide:

Kanban has two documented flavours: the Kanban Guide (Coleman and Vacanti, May 2025), with three practices and four mandatory metrics,^[5] 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.^[10] 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”.^[5] 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,^[23] 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.^[24][25] 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)^[26] Planning, “typically a 2-day event for the entire ART that takes place every 8-12 weeks”.^[27][28] As of October 2026 its site presents “Core SAFe” and an “AI-Native SAFe” variant.^[29] 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.

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.

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.^[12] 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.

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).

# 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.

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.

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 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.

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):

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.

"""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:

python3 flow_metrics.py items.csv 2026-09-11

Expected output (verbatim from the 2026-10-23 run):

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^[14] — 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.

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): 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.

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;^[22] 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”.

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”.^[31]

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,^[24] or a SAFe-style train with PI Planning.^[27] 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.

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.”^[32] One person’s account with second-hand quotes — but the lesson holds: copy the habit of experimenting, not the org chart.

Measure the system with a few metrics whose start and stop points are written down. The Kanban Guide’s four are the core;^[5] the others answer specific questions.

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.^[10][16] 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.^[16]

• 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.^[14] 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.

• 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.
• 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; change approval on ITOps.

The cost of the cadence (worked example). Scrum’s timeboxes are maximums for a one-month Sprint.^[8] 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.^[8]

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”.^[18] 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:^[4] persistent overtime means WIP or scope is too high. Cost of delay across initiatives is on PortfolioOps.

Ceremonies can run while the system stagnates. Close a loop from data to policy, and audit it.

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

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?

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.^[21]

• 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”.^[34] Signal: the Daily Scrum is a status report to a manager. Instead: it belongs to the Developers and the Sprint Goal.^[8]
• Flaccid Scrum. Ceremonies without engineering practice: “progress is slow because the code base is a mess”, since Scrum “deliberately omits any technical practices”.^[31] Pair this page with DevOps.
• Velocity as a target or league table, relaxed WIP limits when people are idle and Sprints without interrupt capacity — covered above.^[13][18][22]
• 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”.^[7]
• 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;^[10] 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”.^[15] Dates are fine; promises without probabilities are not.

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).
• You are in an incident — that needs a command structure (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, DevOps or ITOps.

Hidden responsibilities: clean timestamps, good facilitation, defending WIP limits under pressure, and changing policies when the data say so.

The decision that matters most is not “agile or not” but which cadence and flow controls fit how work arrives.

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

These are leanings, not a score.

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.

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”.

• 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.

• 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.

• 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;^[8] the reason for the chosen framework and the alternative considered are written down.

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 (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: ________

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 ____

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: __________________________________

Sources: the framework pages cited above, opened 2026-10-23.^{[8][5][10][27][28][24]} “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.^[35]

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,^[5][9] 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.^[8] 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.^[8][5]

Is our tool’s “lead time” the same as DORA’s? Almost certainly not: DORA’s runs from commit to production;^[17] Azure Boards’ from item creation to completion.^[16] DORA metrics are taught on 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.^[27][24]

• 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”,^[5] linking upstream discovery (ProductOps) and downstream release (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”).^[12][29] That is guidance, not evidence of outcomes; measure any AI change like other experiments.

• 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.

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”,^[13] 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”.^[8]

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.

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?

2. Three people are idle because Review is at its WIP limit. A manager proposes raising the limit. What do you do?

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?

4. A team calls its “Definition of Ready” part of Scrum. Is it?

5. An operations team misses every Sprint Goal; 40% of its work is unplanned. Name two remedies.

6. Leadership wants to rank teams by velocity. What do you say?

“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.

All sources were opened on 2026-10-23; dates are the sources’ own. Claim-level notes are in research/agileops-ledger.md.

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.