The book Accelerate by Nicole Forsgren, Jez Humble & Gene Kim provides a de-facto standard on how to measure development efficiency, supported by clear scientific findings. It identifies four key metrics that support software delivery performance, namely:

• Lead Time for Changes - how long does it take to go from code committed to code successfully running in production
• Deployment Frequency - how often your software team deploy changes to production
• Mean Time to Recovery - how long it takes to resolve or rollback an error in production
• Change Failure Rate - what percentage of changes to production (software releases and configuration changes) fail

By visibility into these well-established metrics, the teams are enabled to balance speed metrics (Lead Time for Changes, Deployment Frequency) with stability metrics (Change Failure Rate, Mean Time to Recovery), avoiding that increased speed results in suffering quality.

📘

Getting Started

To get started in using DORA, please follow our Setup DORA Metrics guide.

DORA Metrics calculation and validation rules

Deployment Frequency

The deployment frequency metric tracks the frequency of deployments. New deployment frequency data points are populated whenever a release event is received.

The default case is that the service is managed by just one team and in this case only one deployment frequency datapoint is populated for the managing team.

If the service is managed by more than one team, then one deployment frequency data point is populated for every team whose members committed a change in the release.

Example:

1. New commit for service "payment-service" done by the contributor "Max Power" of the team "Payment Pals"
2. New commit for service "payment-service" done by the contributor "Paul Puff" of team "Billing Boys"
3. New release of service "payment-service" including both mentioned commits

This would create a deployment frequency data point for the team "Payment Pals" but also for the team "Billing boys" since they both were involved in that release.

❗️

About commit email addresses

The team member to team association is being done by the commit email address of the changes included in the release. The Deployment Frequency metrics accuracy will improve if the commit email address can be associated with the email of the team member in the team's Fact Sheet, via a subscription for the email address. Otherwise partial deployments will be counted for every team that manages the deployed service.

Lead Time for Changes (LTFC)

The LTFC is essentially how long it takes a team to go from 'code committed' to 'code successfully running in production'.

Every change event contains the commit id of a code change. During processing, it is associated with the corresponding service via its Source property and afterwards stored as an augmented change event in the valuestreams database.

Later on a release event is received. The release event contains a list of changeIds for previously received change events. Amongst those changeIds included in the release event, for each owning team the oldest change is determined. Then, the LTFC metrics are populated, and the LTFC value will equal the time period - in hours - between the time of the first change event and the release event time.

If a changeId can be associated with a team via the change author email then a single LTFC metric is populated, otherwise the event is ignored.

API Reference: Create release event

Validations

• If multiple change events with the same commit(id), service (source) and time are received, then they will be ignored and reported in the logs.

Change Failure Rate (CFR)

The change failure rate(CFR) is the percentage of deployments causing a failure in production.
This means that for a specific time period we need to know how many deployments are associated with incidents.

The algorithm calculates the CFR whenever an incident event is received with a simplistic, time-based approach.
An incident is associated with the last release that was done before the incident was reported.

API Reference: Create incident event and Create release event

Mean time to recovery (MTTR)

The MTTR measures how long it takes to recover a service after an incident occurred. Whenever a new incident event is received, a MTTR metric is populated for every team that was involved in the release of the service associated with the incident. The MTTR is computed as the duration between the creation and resolution of an incident. If there are multiple incidents reported for a timeframe affecting a team and service, then the average of the duration is used.

API Reference: Create incident event