# Measurement: Delivery Performance And DORA

Link **practice** to **outcomes**. This principle sits beside [reliability-slo-incidents.md](reliability-slo-incidents.md): SLOs describe **a service’s** promises to users; **DORA-style** metrics describe **how the organisation delivers** change. Both reduce arguments from taste.

---

## 1. The Four Keys (Conceptual)

Industry research (often summarised as **DORA** or *Accelerate*) ties software delivery performance to four headline metrics:

| Metric | Plain meaning |
| --- | --- |
| **Deployment frequency** | How often you ship **safely** to production |
| **Lead time for changes** | Time from commit to production for a typical change |
| **Change failure rate** | Share of changes causing degraded service / rollback / hotfix |
| **Time to restore** | How long to recover normal service after failure |

Exact definitions evolve with your **value stream** tooling; record **your** definitions in an internal doc and **keep them stable** quarter-to-quarter so trends mean something.

**Why:** These metrics turn “we follow the doctrine” into “delivery is getting safer/faster—or not.”

---

## 2. Map Metrics To Doctrine (Illustrative)

| Four Keys signal | Doctrine touchpoints |
| --- | --- |
| **Deployment frequency** | [build.md](build.md) surfaces, [collaboration.md](collaboration.md) trunk cadence, CI that **promotes** artefacts |
| **Lead time** | Small batches, [trunk-workflow.md](../patterns/trunk-workflow.md), automations that remove wait states |
| **Change failure rate** | [testing-strategy.md](testing-strategy.md), contract validation, [api-boundaries-and-security.md](api-boundaries-and-security.md), release discipline [semantic-versioning.md](semantic-versioning.md) |
| **Time to restore** | [reliability-slo-incidents.md](reliability-slo-incidents.md), [observability.md](observability.md), runbooks [documentation-knowledge.md](documentation-knowledge.md) |

Use the map in **retrospectives**: a rising CFR often traces to **skipped gates** or **unclear ownership**, not “bad luck.”

---

## 2.1 Vulnerability response and remediation signals (adjacent to Four Keys)

**Four Keys** measure **delivery** health; **vulnerability operations** need parallel **SLIs** so “we ship often” does not mask “we never patch.” Track definitions in an internal doc and keep them stable quarter-to-quarter. Examples (rename to match your telemetry):

| SLI | Plain meaning |
| --- | --- |
| **Within remediation target** | Share (or count) of open findings resolved before the estate’s SLA clock—see [dependencies-supply-chain.md](dependencies-supply-chain.md) §2 |
| **Time to triage** | Elapsed from **first signal** (scanner, feed, report) to **prioritised** owner and disposition |
| **Known-exploited backlog** | Count and age of issues matching **weaponisation** feeds (e.g. [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)) still open |
| **Security debt beyond policy** | Findings older than the published SLA without an approved exception |

**Why:** NIST SSDF **RV** and sector practice expect **measurable** response; **DORA** throughput without these signals **games** behaviour—pair with [dependencies-supply-chain.md](dependencies-supply-chain.md) §2 and [secure-development-lifecycle.md](secure-development-lifecycle.md) §3.

---

## 3. What This Document Does Not Replace

- **Product metrics** (activation, revenue) — still required for product health.
- **Security and compliance attestations** — complementary; use [dependencies-supply-chain.md](dependencies-supply-chain.md), audits, ASVS-style reviews where applicable.
- **Individual developer productivity theatre** — avoid using Four Keys to punish people; use them to **inspect the system**.

---

## 4. SPACE: Developer Experience Beyond Throughput

- **SPACE** (Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow) frames **developer experience** using **multiple** dimensions—not only **lines of code** or **story points**.
- Use SPACE-style surveys and **qualitative** interviews alongside DORA metrics to catch **burnout**, **tooling friction**, and **review** bottlenecks that Four Keys can **miss**.
- Developer-experience operating rules live in [developer-experience.md](developer-experience.md); a lightweight review tool lives in [developer-experience-scorecard.md](../checklists/developer-experience-scorecard.md).

**Why:** Microsoft Research’s SPACE work shows **single-metric** productivity measures **game** behaviour and hide systemic problems.

---

## Rationale And Decisions

| Decision | Rationale |
| --- | --- |
| Separate from SLO doc | SLOs are **per-service** promises; DORA metrics are **delivery system** health—both needed. |
| Reference research, don’t replicate | Definitions and benchmarks are maintained by **DORA** and secondary literature—link out. |
| SPACE complements DORA | **Throughput** without **well-being** signals misleads leadership during crunch. |

---

## References

- **DORA** (Google Cloud DevOps Research): https://dora.dev/  
- *Accelerate* (Forsgren, Humble, Kim) — research foundation for Four Keys  
- ACM Queue — **The SPACE of Developer Productivity** (Forsgren et al.): https://queue.acm.org/detail.cfm?id=3454124  
- [reliability-slo-incidents.md](reliability-slo-incidents.md) — SLOs, error budgets, incidents  
