Use the current five DORA measures with a practical event log. Separate delivery evidence from individual productivity scores and misleading averages.
A small team needs measurements it can explain. Begin with one application and the decisions you want to improve: are changes waiting too long, do releases repeatedly need repair, or is recovery uncertain? Collecting every available event before agreeing on those questions creates a reporting project. A short, inspectable release log can reveal more than an impressive dashboard with unclear definitions.
Use the current definitions
DORA now describes five measures: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. The last distinguishes unplanned deployments arising from production incidents. Check the official definitions when configuring a tool; an older four-metric dashboard may use different boundaries.
Build a release event dictionary
For your application, write down what counts as production, a deployment, an incident caused by a change and a restored service. Decide how to handle feature flags, batch releases and multiple commits in one deployment. These are local collection rules, not permission to rename a convenient timestamp as a different measure. Keep the rules beside the report and retain enough identifiers to inspect a surprising result.
| Record | Useful fields | Reason |
|---|---|---|
| Change | Commit identity, committed time and release identity | Connect the implemented change to production |
| Deployment | Application, environment, start, outcome and completion | Separate delivery events from build attempts |
| Intervention | Related release, customer impact and recovery evidence | Explain why a change required repair |
| Repair release | Incident link and whether the release was unplanned | Distinguish planned delivery from incident-driven work |
Read small samples carefully
Show observation counts and missing records alongside trends. With only a few deployments, one difficult release can move a percentage sharply; inspect that case rather than declaring the team better or worse. Preserve distributions where possible because an average can hide one long queue. A period without a failed deployment does not establish how quickly the team would recover from the next one.
Choose one experiment
Use the data to investigate a specific constraint, such as delayed review, unstable tests or risky release batches. Agree one process change, an owner and a review date. Keep customer outcomes and reliability evidence alongside delivery measures. Do not compare unrelated applications or rank individual engineers: their work and operating constraints differ. A useful measurement practice ends with an actionable decision, then checks whether that decision improved delivery.
- Engineering process and DevOps
- CI/CD Pipeline Audit: A Release Reliability Checklist
- Why Engineering Delivery Slows Down as a Team Grows
Frequently asked questions
Are there still only four DORA metrics?
The current DORA guide describes five. Verify the definitions and collection boundaries used by your reporting product before comparing its numbers with another source.
Can we start with a spreadsheet?
Yes. A release log with reliable identifiers and agreed definitions is a reasonable beginning. Automate collection when manual effort or gaps justify it.
What if we deploy infrequently?
Show the sample size and inspect individual changes. Avoid strong conclusions from a percentage based on only a few releases.
Should we use these metrics for developer bonuses?
No. They describe a delivery system. Individual targets can encourage changes to the measurement rather than improvements to customer outcomes.
How do we measure a release behind a feature flag?
Document deployment and customer exposure separately. Apply a consistent deployment definition and use exposure records to investigate the actual user impact.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
CI/CD pipeline audit: a release reliability checklist
Audit the path from commit to production: artifact identity, approvals, migrations, verification and recovery. Turn release risks into measurable fixes.
Why engineering delivery slows as a team grows
Find delivery bottlenecks in queues, shared ownership and dependencies. Use work-item evidence to improve flow before adding more people or meetings.
Code review process: reduce waiting without losing quality
Design code reviews around small changes, explicit risk, reviewer ownership and useful feedback. Measure waiting time without turning review into a quota.