# Software Delivery Performance Report: [Organisation or product area] [Quarter]

> Quarterly report on software delivery performance for a set of
> applications or services: the five DORA software delivery metrics
> measured per service with explicit definitions and formulas, data
> quality, a capability assessment, perception data from the developer
> survey, findings and actions with owners and dates. Based on the DORA
> metrics guide published at dora.dev (page updated 2026-01-05, CC BY
> 4.0) and the DORA capability catalogue, with perception data framed by
> the SPACE (ACM Queue, 2021) and DevEx (ACM Queue, 2023) frameworks.
> Replace every `[bracketed]` value and every row marked *Example*. The
> worked example uses Corvid Commerce, a fictional SaaS company.

<!--
Guidance: How to use this template
- One report per quarter per reporting unit (a product area, a group of
  teams, or the whole engineering organisation). Measure each metric per
  application or service, then summarise. DORA advises against blending
  very different services into one number.
- Fill section 2 (method and definitions) before the first report and
  keep it stable. If a definition changes, record it in 2.4 and mark the
  affected trend lines as not comparable.
- The report is a learning tool for teams and leaders, not a scorecard
  for individuals. Section 11 sets the rules; read them aloud at the
  review meeting if needed.
- Pull perception data from the Developer Experience Survey
  (`dev/developer-experience-survey`) run in the same quarter. Feed
  targets back into Engineering Strategy (`dev/engineering-strategy`)
  section 6 and debt items into the Technical Debt Register
  (`architecture/tech-debt-register`).
- Related documents: CI/CD Pipeline Design (`dev/ci-cd-pipeline-design`),
  Versioning and Release Policy (`dev/versioning-release-policy`),
  Postmortem (`dev/postmortem`), Incident Severity Matrix
  (`ops/incident-severity-matrix`), Value Stream Map
  (`architecture/value-stream-map`), Internal Developer Platform Charter
  (`architecture/internal-developer-platform-charter`).
-->

## Document control

<!-- Guidance: Identify the period, the services in scope and who owns the numbers. A correction to published figures is a new minor version with the reason in the revision history. -->

| Field | Value |
|---|---|
| Document ID | [DPR-2026-Q3] |
| Reporting unit | [Organisation, product area or team group] |
| Reporting period | [YYYY-MM-DD] to [YYYY-MM-DD] |
| Services in scope | [Number] services, listed in 2.1 |
| Data extracted on | YYYY-MM-DD |
| Metrics definition version | [MDEF-1.2] (section 2.2) |
| Version | [0.1] |
| Status | [Draft / In review / Published / Corrected] |
| Owner | [@engineering-effectiveness-lead] |
| Approvers/reviewers | [@vp-engineering], [@platform-lead], [@sre-lead], [@team-leads] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Previous report | [DPR-2026-Q2] |
| Related documents | [Engineering strategy], [Developer experience survey results], [Tech debt register] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| VP Engineering | [@name] | [Approve / Approve with changes / Reject] | YYYY-MM-DD |
| Platform lead | [@name] | [Decision] | YYYY-MM-DD |
| SRE lead | [@name] | [Decision] | YYYY-MM-DD |
| Engineering effectiveness lead (author) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from automated extract |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Published after team review |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Corrected payments-gateway rework count after incident relinking |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Executive summary](#1-executive-summary)
2. [Scope and method](#2-scope-and-method)
3. [Delivery metrics results](#3-delivery-metrics-results)
4. [Data quality and confidence](#4-data-quality-and-confidence)
5. [Capability assessment](#5-capability-assessment)
6. [Perception data](#6-perception-data)
7. [AI-assisted development](#7-ai-assisted-development)
8. [Findings](#8-findings)
9. [Actions](#9-actions)
10. [Follow-up of previous actions](#10-follow-up-of-previous-actions)
11. [Use and misuse of these metrics](#11-use-and-misuse-of-these-metrics)
12. [Glossary and references](#12-glossary-and-references)

## 1. Executive summary

<!-- Guidance: Write this last, in five to eight sentences a director can read in one minute. State what changed, why it matters, and what you will do. Pitfall: listing numbers without saying whether they are good or bad for this context and what decision they support. -->

*Example (Corvid Commerce, Q3 2026, checkout product area):*

- **Throughput improved on checkout-api.** Deployment frequency rose from
  12.0 to 14.0 deployments per week and median change lead time fell
  from 29 to 21 hours, after the merge queue and parallel test stages went
  live (action ACT-2026Q2-03).
- **Instability is concentrated in payments-gateway.** It has the highest
  change fail rate (7.7%) and deployment rework rate (10.3%) of the three
  services, and a median failed deployment recovery time of 3.1 hours,
  because rollback is manual and depends on one engineer.
- **Review wait is now the largest share of lead time** on checkout-api
  (9 of 21 hours), and developers rate "waiting for code review" as their
  top friction in the Q3 survey.
- **Decisions requested:** fund automated rollback for payments-gateway
  in Q4 (ACT-2026Q3-01) and adopt a review service level for the checkout
  teams (ACT-2026Q3-02).

## 2. Scope and method

<!-- Guidance: Define exactly what is measured so that numbers are comparable across quarters. Questions: which services, which environment counts as production, what is a deployment, what counts as a failure? Pitfall: changing a definition silently and reporting an improvement that is only a measurement change. -->

### 2.1 Services in scope

Measure each metric per application or service. A service here is a
unit that is deployed independently and has a named owning team.

| Service ID | Service | Owning team | Deployment model | Production definition | In scope since |
|---|---|---|---|---|---|
| SVC-001 *(Example)* | checkout-api | Team Kestrel | Continuous deployment behind feature flags | All three production regions | 2025-Q1 |
| SVC-002 *(Example)* | payments-gateway | Team Heron | Scheduled release three times a week (Mon, Wed, Fri), release candidate cut 48 hours before each window, manual approval | Primary region plus disaster recovery region | 2025-Q3 |
| SVC-003 *(Example)* | catalog-search | Team Wren | Continuous deployment, canary 5% then 100% | Production cluster, all tenants | 2026-Q1 |
| [SVC-NNN] | [Service] | [Team] | [Model] | [What counts as production] | [Quarter] |

Excluded this quarter: [list services and reason, *Example:* internal
admin tools with fewer than 5 deployments in the period, reported
annually instead].

### 2.2 Metric definitions

The five metrics and their grouping follow the DORA metrics guide at
dora.dev. Throughput metrics describe how quickly and how often changes
move to production; instability metrics describe how often deployments
go wrong and cause extra work. The local measurement rules in the last
column are this organisation's choices and must be stated because DORA
leaves them to each team.

| ID | Metric | Group | DORA definition (paraphrased) | Formula | Local measurement rule |
|---|---|---|---|---|---|
| DM-01 | Change lead time | Throughput | Time for a change to go from being committed to version control to running in production | For each change: `t(running in production) - t(commit)`; report the median and 85th percentile over all changes deployed in the period | *Example:* Start at the first commit of the merged pull request; end when the deployment containing the merge commit completes in the last production region |
| DM-02 | Deployment frequency | Throughput | How often application changes are deployed to production | `production deployments in period / weeks in period`; also report deploy days as a share of working days | *Example:* Count successful and failed deployments; exclude configuration-only pushes that do not change the application artefact |
| DM-03 | Failed deployment recovery time | Throughput | Time to recover when a deployment fails and needs immediate intervention | For each failed deployment: `t(service restored) - t(failed deployment completed)`; report the median | *Example:* Restored means the incident record shows impact ended, whether by rollback, roll forward or flag off |
| DM-04 | Change fail rate | Instability | Share of deployments that need immediate intervention afterwards, such as a rollback or hotfix | `failed deployments / total deployments` | *Example:* A deployment is failed when it is linked to an incident of any severity in the Incident Severity Matrix or is rolled back within 24 hours |
| DM-05 | Deployment rework rate | Instability | Share of deployments that were not planned and were made because of an incident in production | `unplanned deployments caused by a production incident / total deployments` | *Example:* A deployment is rework when its change record links an incident ID as the reason |

Notes on the definitions:

1. A deployment can be both a failure (it caused the incident) and the
   cause of a rework deployment (the hotfix that followed). The failed
   deployment counts in DM-04; the hotfix counts in DM-05. Do not count
   one event twice in the same metric. A rework deployment that itself
   fails counts as a failure in DM-04 as well.
2. Use medians for time-based metrics. Means are distorted by a few very
   long changes. Report the 85th percentile next to the median to show
   the tail.
3. Report counts next to rates. A change fail rate of 50% on 2
   deployments is noise, not a trend.
4. Older DORA material used other names, such as "time to restore
   service" and "mean time to recovery". If your history uses them,
   record the mapping in 2.4.

### 2.3 Data sources and pipeline

| Source ID | Data | System | Owner | Extraction |
|---|---|---|---|---|
| SRC-01 *(Example)* | Commit and pull request timestamps | Git hosting service | [@platform-lead] | Nightly API export |
| SRC-02 *(Example)* | Deployment start, end, result, artefact version, region | CI/CD platform deployment events | [@platform-lead] | Webhook into the metrics store |
| SRC-03 *(Example)* | Incident start, impact end, severity, linked deployment | Incident management tool | [@sre-lead] | Nightly API export |
| SRC-04 *(Example)* | Change records with reason code (planned, incident) | Change management in the CI/CD platform | [@release-manager] | Webhook |
| [SRC-NN] | [Data] | [System] | [@owner] | [Method] |

```mermaid
flowchart LR
  VCS["Version control: commits and merges"] --> STORE["Metrics store"]
  CD["CI/CD: deployment events"] --> STORE
  INC["Incident tool: incidents linked to deployments"] --> STORE
  CHG["Change records: reason codes"] --> STORE
  STORE --> CALC["Per-service calculation (MDEF version)"]
  CALC --> QA["Data quality checks (section 4)"]
  QA --> REP["This report and team dashboards"]
```

### 2.4 Local adaptations and definition changes

| Change ID | Date | Change | Reason | Metrics affected | Comparable with earlier quarters |
|---|---|---|---|---|---|
| MDEF-CHG-01 *(Example)* | 2026-01-15 | Added deployment rework rate as the fifth metric | Aligned with the updated DORA metrics guide | DM-05 | No history before 2026-Q1 |
| MDEF-CHG-02 *(Example)* | 2026-04-01 | Lead time end point moved from "first region" to "last region" | Multi-region rollout made the first-region time misleading | DM-01 | No; Q1 and earlier restated where raw data allowed |
| [MDEF-CHG-NN] | YYYY-MM-DD | [Change] | [Reason] | [DM IDs] | [Yes / No / Restated] |

## 3. Delivery metrics results

<!-- Guidance: Show the numbers per service with counts, the previous quarter and the direction. Interpret each line in one sentence. Questions: is the change larger than normal quarter-to-quarter noise? What explains it? Pitfall: ranking teams against each other on a single chart. -->

### 3.1 Results per service

Period: *Example:* 2026-07-01 to 2026-09-30, 13 weeks.

| Service | Deployments | Deployment frequency (per week) | Change lead time median (p85) | Failed deployments | Change fail rate | Failed deployment recovery time median | Rework deployments | Deployment rework rate |
|---|---|---|---|---|---|---|---|---|
| checkout-api *(Example)* | 182 | 14.0 | 21 h (52 h) | 9 | 4.9% | 48 min | 7 | 3.8% |
| payments-gateway *(Example)* | 39 | 3.0 | 149 h (230 h) | 3 | 7.7% | 3.1 h | 4 | 10.3% |
| catalog-search *(Example)* | 96 | 7.4 | 30 h (66 h) | 2 | 2.1% | 25 min | 2 | 2.1% |
| [Service] | [N] | [N / weeks] | [h (h)] | [N] | [failed / deployments] | [time] | [N] | [rework / deployments] |

Check the arithmetic before publishing. *Example:* checkout-api
182 / 13 = 14.0 per week; 9 / 182 = 4.9%; 7 / 182 = 3.8%.
payments-gateway 39 / 13 = 3.0; 3 / 39 = 7.7%; 4 / 39 = 10.3%.
catalog-search 96 / 13 = 7.4; 2 / 96 = 2.1% for both instability metrics.

### 3.2 Trend against the previous quarter

| Service | Metric | Previous quarter | This quarter | Direction | Comment |
|---|---|---|---|---|---|
| checkout-api *(Example)* | Deployment frequency | 12.0 per week (156 deployments) | 14.0 per week (182) | Improved | Merge queue live since 2026-07-08 |
| checkout-api *(Example)* | Change lead time median | 29 h | 21 h | Improved | Review wait unchanged; build and queue time fell |
| checkout-api *(Example)* | Change fail rate | 7.1% (11 of 156) | 4.9% (9 of 182) | Improved | Contract tests added to the pipeline |
| checkout-api *(Example)* | Deployment rework rate | 5.8% (9 of 156) | 3.8% (7 of 182) | Improved | Follows the change fail rate |
| checkout-api *(Example)* | Failed deployment recovery time median | 71 min | 48 min | Improved | Flag-off runbook used in 6 of 9 failures |
| payments-gateway *(Example)* | Change fail rate | 7.5% (3 of 40) | 7.7% (3 of 39) | Flat | Below the size where a change is meaningful |
| [Service] | [Metric] | [Value (count)] | [Value (count)] | [Improved / Flat / Worse] | [Explanation] |

Treat a movement as real only when the counts behind it are large enough
and the cause is known. *Example rule:* do not call a rate change a
trend when the service had fewer than 30 deployments in either quarter
or when fewer than 5 events sit behind the rate.

### 3.3 Change lead time breakdown

Splitting lead time into stages shows where waiting happens. Use the
median for each stage; stage medians do not always add up exactly to
the overall median, so state any residual. In the example they add up
because the rows were reconciled against the overall median.

| Stage | checkout-api median *(Example)* | payments-gateway median *(Example)* | What drives it |
|---|---|---|---|
| First commit to pull request opened | 2.0 h | 4.0 h | Size of the change, local working practice |
| Pull request opened to first review | 9.0 h | 31.0 h | Reviewer availability, size of change |
| Review to merge | 0.8 h | 6.0 h | Rework after review, approvals |
| Merge to deployment start | 8.2 h | 100.0 h | Release schedule, merge queue, change approval |
| Deployment duration (all regions) | 1.0 h | 8.0 h | Pipeline stages, canary bake time |
| **Total** | **21.0 h** | **149.0 h** | |

*Example reading:* payments-gateway spends 100 of 149 hours (67%) after
merge: the release candidate is cut 48 hours before each window and
changes that miss a cut wait for the next one. Of the 39 release windows
in 13 weeks, 35 were used (4 fell in a change freeze); with the 4
unplanned rework deployments this gives the 39 deployments in 3.1. Batch
size, not engineering speed, sets its lead time.

### 3.4 Interpretation

- [Service]: [what the numbers say, the likely cause, the confidence].
- *Example:* checkout-api throughput and stability improved together,
  which matches DORA's finding that speed and stability are not a
  trade-off for most teams.
- *Example:* payments-gateway combines low throughput with high rework.
  Larger batches make each deployment riskier and recovery slower. See
  finding FND-01.

## 4. Data quality and confidence

<!-- Guidance: Say how far readers can trust each number. Questions: what share of deployments are linked to commits and incidents? Which events were corrected by hand? Pitfall: publishing a precise-looking rate built on half-linked data. -->

| Check ID | Check | Threshold *(Example)* | Result this quarter | Status |
|---|---|---|---|---|
| DQ-01 | Deployments with a resolvable artefact and commit list | ≥ 98% | *Example:* 315 of 317 (99.4%) | Pass |
| DQ-02 | Incidents of severity 1 to 3 with a deployment link or an explicit "not deployment-related" flag | ≥ 95% | *Example:* 41 of 45 (91.1%) | Fail |
| DQ-03 | Change records with a reason code | 100% | *Example:* 317 of 317 | Pass |
| DQ-04 | Manual corrections to raw data | Logged with reason | *Example:* 3 corrections, all logged | Pass |
| DQ-05 | Clock source consistent across systems (UTC) | Yes | Yes | Pass |
| [DQ-NN] | [Check] | [Threshold] | [Result] | [Pass / Fail] |

The deployment total in DQ-01 is 182 + 39 + 96 = 317. Because DQ-02
failed, the change fail rates in 3.1 may be understated: up to 4
incidents may belong to a deployment. Confidence:

| Metric | Confidence | Reason |
|---|---|---|
| Deployment frequency | High | Directly from pipeline events |
| Change lead time | High | Commit and deployment data complete |
| Change fail rate | Medium | Incident linking below threshold (DQ-02) |
| Failed deployment recovery time | Medium | Depends on incident impact-end timestamps entered by hand |
| Deployment rework rate | Medium | Reason codes complete, but depend on correct incident links |

## 5. Capability assessment

<!-- Guidance: Metrics show outcomes; capabilities explain them. Assess the capabilities that matter most for your constraint, with evidence. Questions: which capability, if improved, would move the weakest metric? Pitfall: scoring all capabilities every quarter with no evidence and no decision. -->

DORA publishes a catalogue of capabilities that its research links to
better software delivery and organisational performance, at
dora.dev/capabilities. Assess a short list each quarter, chosen for the
current constraint, and rotate the rest. Use a four-step scale:
1 = not in place, 2 = partial, 3 = in place for most services,
4 = in place and measured. Base each score on evidence, not opinion.

| Capability (dora.dev name) | Service or scope | Score last quarter | Score this quarter | Evidence | Gap and next step |
|---|---|---|---|---|---|
| Continuous integration *(Example)* | All three services | 3 | 3 | Every merge triggers the full pipeline; median build 11 min | Flaky tests at 2.3% of runs; see ACT-2026Q3-04 |
| Deployment automation *(Example)* | payments-gateway | 2 | 2 | Deploy is scripted; rollback is a manual 14-step runbook | Automate rollback (ACT-2026Q3-01) |
| Working in small batches *(Example)* | payments-gateway | 1 | 1 | Median 23 merged pull requests per release | Move to daily releases after rollback automation |
| Streamlining change approval *(Example)* | payments-gateway | 2 | 2 | Every release needs a human approval regardless of risk | Risk-based approval in the Versioning and Release Policy |
| Trunk-based development *(Example)* | checkout-api, catalog-search | 3 | 4 | Branches live under one day for 92% of pull requests | Hold |
| Monitoring and observability *(Example)* | All | 3 | 3 | SLOs exist for all three services | Add deployment markers to dashboards |
| Code maintainability *(Example)* | checkout-api | 2 | 2 | 14 open high-interest items in the debt register | Budget per Tech Debt Register section 5 |
| [Capability] | [Scope] | [1 to 4] | [1 to 4] | [Evidence] | [Next step] |

Capabilities from the catalogue that are often relevant to delivery
performance include: version control, continuous delivery, test
automation, test data management, database change management, loosely
coupled teams, empowering teams to choose tools, documentation quality,
pervasive security, flexible infrastructure, visibility of work in the
value stream, work in process limits, generative organisational culture,
learning culture, job satisfaction and well-being. Check the current
catalogue for the full list and definitions.

## 6. Perception data

<!-- Guidance: System data shows what happened; people explain why and reveal friction that systems do not record. Use survey results from the same quarter. Questions: do perceptions agree with the system metrics? Where they disagree, which is right? Pitfall: dismissing survey data as "soft" when it disagrees with dashboards. -->

Perception data comes from the Developer Experience Survey
(`dev/developer-experience-survey`). The DevEx framework (Noda, Storey,
Forsgren and Greiler, ACM Queue 2023) groups developer experience into
feedback loops, cognitive load and flow state. The SPACE framework
(Forsgren and others, ACM Queue 2021) argues that productivity needs
several dimensions together: satisfaction and well-being, performance,
activity, communication and collaboration, and efficiency and flow.
Report only aggregated results that meet the survey's minimum group
size.

| Item ID | Survey item (short) | Framework dimension | Respondents in scope | Favourable last quarter | Favourable this quarter | Agrees with system data? |
|---|---|---|---|---|---|---|
| DX-FL-02 *(Example)* | Waiting for code review rarely slows down my work | DevEx: feedback loops | 46 | 41% | 39% | Yes: review wait is 9 of 21 h (3.3) |
| DX-FL-01 *(Example)* | CI results arrive fast enough that I stay in context | DevEx: feedback loops | 46 | 52% | 71% | Yes: build time fell after parallel stages |
| DX-CL-03 *(Example)* | I can release my changes without depending on one specific person (Payments group) | DevEx: cognitive load | 12 | 25% | 25% | Yes: single-person rollback dependency |
| DX-FS-01 *(Example)* | I get enough uninterrupted time for focused work | DevEx: flow state | 46 | 48% | 50% | No system equivalent |
| DX-SAT-01 *(Example)* | I would recommend my team's tooling to a peer (checkout and payments groups) | SPACE: satisfaction | 58 | 55% | 62% | Partly |
| [Item ID] | [Item] | [Dimension] | [n] | [%] | [%] | [Note] |

"Favourable" is the share of respondents choosing the top two points
on a five-point agreement scale. The respondents column gives the group
size; with 12 respondents, one person changes the result by about 8
percentage points, so read small groups as signals, not measurements.

## 7. AI-assisted development

<!-- Guidance: Optional. Use when teams adopt AI coding assistants or agents. Questions: has adoption changed throughput or instability? Do the enabling capabilities exist? Pitfall: attributing a change in delivery metrics to AI without a comparison or a known mechanism. -->

The DORA *State of AI-assisted Software Development* report (2025)
found that AI acts as an amplifier: it magnifies the strengths and
weaknesses of the existing system. The DORA capability catalogue tags
seven capabilities as part of its AI Capabilities Model, listed on
dora.dev at the time of writing as: clear and communicated AI stance,
healthy data ecosystems, AI-accessible internal data, version control,
working in small batches, user-centric focus, and platform engineering.
Check the current list before use.

| Item | Value this quarter *(Example)* | Comment |
|---|---|---|
| Developers using an approved AI assistant weekly (survey) | 78% of 168 respondents | Up from 64% |
| Share of merged pull requests with AI-assisted changes (self-declared label) | 41% on checkout-api | Labelling is voluntary; treat as a lower bound |
| Change fail rate, AI-labelled vs other pull requests | Not reported | Fewer than 5 failures in either group |
| AI capability with the largest gap | Working in small batches (payments-gateway) | Same constraint as in section 5 |
| Policy reference | AI Usage Policy (`ai-data/ai-usage-policy`) | [Version] |

## 8. Findings

<!-- Guidance: Each finding states the observation, the evidence from sections 3 to 7, the likely cause and the impact. Keep to the three to six that matter. Pitfall: findings that restate a number without a cause. -->

| Finding ID | Finding | Evidence | Likely cause | Impact | Severity |
|---|---|---|---|---|---|
| FND-01 *(Example)* | payments-gateway has the highest instability and slowest recovery | 3.1: CFR 7.7%, rework 10.3%, recovery 3.1 h | Large batches (23 PRs per release) and manual rollback known by one engineer | Customer-facing payment errors last longer; on-call load on Team Heron | High |
| FND-02 *(Example)* | Review wait dominates checkout-api lead time | 3.3: 9.0 of 21.0 h; DX-FL-02 at 39% favourable | No review rota; reviewers concentrated in two seniors | Context switching and batching of changes | Medium |
| FND-03 *(Example)* | Incident-to-deployment linking is incomplete | DQ-02 at 91.1% | Linking is manual in the incident tool | Instability metrics may be understated | Medium |
| FND-04 *(Example)* | Flaky tests waste CI capacity | 2.3% of pipeline runs fail and pass on retry | Shared test data across parallel stages | Slower feedback, lower trust in CI | Low |
| [FND-NN] | [Finding] | [Section and data] | [Cause] | [Impact] | [High / Medium / Low] |

## 9. Actions

<!-- Guidance: Every High finding needs an action with an owner, a date and the metric you expect to move. Limit to what the teams can absorb next quarter. Pitfall: actions with no owner, or ten actions that compete for the same people. -->

| Action ID | Action | Finding | Owner | Due | Expected effect | Measure of success |
|---|---|---|---|---|---|---|
| ACT-2026Q3-01 *(Example)* | Automate one-step rollback for payments-gateway and train two more engineers | FND-01 | [@team-heron-lead] | 2026-11-30 | Lower recovery time, then smaller batches | Recovery time median below 1 h by Q1 2027 |
| ACT-2026Q3-02 *(Example)* | Introduce a review rota and a review service level of 4 working hours for the checkout teams | FND-02 | [@checkout-em] | 2026-10-31 | Lower review wait | Stage median below 4 h; DX-FL-02 above 55% |
| ACT-2026Q3-03 *(Example)* | Make the deployment link a required field when closing a severity 1 to 3 incident | FND-03 | [@sre-lead] | 2026-10-31 | DQ-02 at 100% | DQ-02 Pass in Q4 |
| ACT-2026Q3-04 *(Example)* | Isolate test data per parallel stage and quarantine known flaky tests | FND-04 | [@platform-lead] | 2026-12-15 | Fewer retries | Flaky rate below 0.5% of runs |
| [ACT-YYYYQn-NN] | [Action] | [FND ID] | [@owner] | YYYY-MM-DD | [Effect] | [Measure] |

## 10. Follow-up of previous actions

<!-- Guidance: Close the loop. Report every action from the previous report with its outcome, including the ones that did not work. Pitfall: dropping actions silently. -->

| Action ID | Action | Owner | Status | Outcome |
|---|---|---|---|---|
| ACT-2026Q2-03 *(Example)* | Merge queue and parallel test stages for checkout-api | [@platform-lead] | Done 2026-07-08 | Lead time median 29 h to 21 h; frequency 12.0 to 14.0 per week |
| ACT-2026Q2-04 *(Example)* | Contract tests between checkout-api and payments-gateway | [@team-kestrel-lead] | Done 2026-08-02 | Checkout change fail rate 7.1% to 4.9% |
| ACT-2026Q2-05 *(Example)* | Daily release for payments-gateway | [@team-heron-lead] | Deferred | Blocked by manual rollback; replaced by ACT-2026Q3-01 |
| [ACT-ID] | [Action] | [@owner] | [Done / In progress / Deferred / Dropped] | [Outcome and evidence] |

## 11. Use and misuse of these metrics

<!-- Guidance: State the rules that keep the metrics useful. Agree them with team leads and repeat them in every report. Pitfall: a target on one metric that teams can meet by harming another, such as more deployments of empty changes. -->

The following rules apply to everyone who reads or uses this report:

1. Metrics describe services and systems, not people. Do not use them in
   individual performance reviews, compensation or ranking.
2. Do not compare teams that run very different services on one chart.
   Compare a service with its own history.
3. Always read throughput and instability together. A target on one group
   alone invites gaming of the other.
4. Teams own their numbers. Each team reviews its figures before
   publication and can add a context note.
5. When a metric is turned into a target, record the target, the reason
   and the counter-metric that will detect gaming.
6. Treat survey data as confidential aggregates under the rules in the
   Developer Experience Survey; never try to identify respondents.
7. Publish corrections openly in the revision history.

Other measurement frameworks exist, such as SPACE, DevEx and the DX Core
4. Use them to choose complementary measures, not to replace the
definitions in section 2.

## 12. Glossary and references

<!-- Guidance: Define terms the way this report uses them, and list the sources with the version or date you checked. -->

### 12.1 Glossary

| Term | Meaning in this report |
|---|---|
| Deployment | A change to the application artefact running in production, as recorded by the CI/CD platform |
| Failed deployment | A deployment that needs immediate intervention, such as a rollback, roll forward, hotfix or feature flag off |
| Rework deployment | An unplanned deployment made because of a production incident |
| Change lead time | Time from commit to running in production for one change |
| p85 | 85th percentile: 85% of values are at or below it |
| Favourable | Top two points on a five-point agreement scale |
| Capability | A practice or condition that DORA research associates with better delivery and organisational outcomes |
| Throughput / instability | The two groups of DORA software delivery metrics |

### 12.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| DORA, Software delivery performance metrics guide, https://dora.dev/guides/dora-metrics/ | Page updated 2026-01-05; checked 2026-10-24 | Names, grouping and definitions of the five metrics (paraphrased) |
| DORA, Capabilities catalogue, https://dora.dev/capabilities/ | Checked 2026-10-24 | Capability names and AI Capabilities Model tags |
| DORA, State of AI-assisted Software Development 2025, https://dora.dev/research/2025/dora-report/ | 2025 edition (published September 2025); no 2026 edition found on 2026-10-24 | AI as an amplifier finding |
| Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, "The SPACE of Developer Productivity", ACM Queue 19(1) | 2021 | Concept of five productivity dimensions (cited, not reproduced) |
| Noda, Storey, Forsgren, Greiler, "DevEx: What Actually Drives Productivity", ACM Queue 21(2), DOI 10.1145/3595878 | 2023 | Concept of three developer experience dimensions (cited, not reproduced) |
| DX Core 4 (DX) | 2024 | Named only as another framework |
| [Internal metrics definition] | [MDEF version] | [Local rules] |

## Standard and licence note

Based on the DORA software delivery performance metrics guide and the
DORA capabilities catalogue published at dora.dev by Google LLC under
the Creative Commons Attribution 4.0 International licence (CC BY 4.0,
https://creativecommons.org/licenses/by/4.0/); metric definitions are
paraphrased and adapted, and changes are this template's own. The SPACE
and DevEx frameworks are cited from their ACM Queue articles for their
concepts only; no text from those articles is reproduced. DX Core 4 is
named only. Google, DORA, ACM and DX are trademarks of their owners;
this template is not affiliated with or endorsed by them. This template
is original text written for this collection. Check the current
official guide and reports at dora.dev before use, as definitions and
capability lists are updated. Template licence: MIT.