Software Delivery Performance Report Template (DORA Metrics)

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.

Document control

Approvals

Revision history

Contents

1. Executive summary
2. Scope and method
3. Delivery metrics results
4. Data quality and confidence
5. Capability assessment
6. Perception data
7. AI-assisted development
8. Findings
9. Actions
10. Follow-up of previous actions
11. Use and misuse of these metrics
12. Glossary and references

1. Executive summary

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

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.

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.

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

2.4 Local adaptations and definition changes

3. Delivery metrics results

3.1 Results per service

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

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

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.

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

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:

5. Capability assessment

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.

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

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.

"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

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.

8. Findings

9. Actions

10. Follow-up of previous actions

11. Use and misuse of these metrics

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

12.1 Glossary

12.2 References

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.