DORA is a set of four software delivery performance measures used to understand engineering-team performance and connect delivery practices with organizational value. section 2.4.5 section 2.5
Track four complementary signals:
- Deployment frequency: how often the team deploys code to production. section 2.4.5
- Mean change lead time: how long committed code takes to run successfully in production; also called cycle time. section 2.4.5
- Mean time to restore: how quickly the team recovers to a functional state after a production issue. section 2.5
- Change failure rate: how often changes result in failure. section 2.5
Table 2.5 DORA engineering metrics on software engineering team performance
|
DORA metric
|
How it’s measured and how to interpret the metric
|
Why it’s important
|
Why an organization should care
|
|---|---|---|---|
|
Deployment frequency
How often a software engineering team deploys code to production
|
Deployments per day
 Good: On-demand, high frequency, multiple deploys a day
 Bad: Low frequency, between once a month and once every 6 months
|
Indicative of how efficient a team’s working and releasing processes are
|
Indicative of how often a team provides value to customers
|
|
Mean change lead time
Time it takes from code being committed to code successfully running
Change lead time is also known as
cycle time.
|
Average time for committed changes to run successfully in production
Good: >1 day
Bad: 1–6 months
|
Tracks the pace of a team; faster teams have optimized processes; slower teams can be a sign of waste or inefficiency in the process.
|
Faster delivery encourages an increase in revenue and improved customer renewal rates
|
|
Mean time to restore
How quickly a software engineering team recovers from failure
|
The average time between a production bug/failure being reported and that problem being fixed
Good: Less than 1 hour
Bad: Between 1 week and 1 month
|
Indicative of how quickly a team can understand and resolve problems that occur in production; low mean times to recovery give teams confidence that they can restore to a functional state if production is affected
|
Any downtime has negative effects on an organization. The quicker your system gets back to a functional state, the less severe the effect on the organization.
|
|
Change failure rate
How often a software engineering team releases a change to production that causes a failure
|
Ratio; number of failures to number of deployments (
calculated as a percentage)
Good: Rate 0–15%
Bad: Rate 46–60%
|
Indicative of the quality of software the team builds; high change failure rates suggest lower-quality software that frustrates customers.
|
Fixing bugs and rolling back code is costly; doing so takes time away from building new features that bring value to customers.
|
Use the metric table to compare each measure’s calculation, interpretation, importance, and organizational relevance. section 2.4.5
Teams can use the measures to categorize their current performance as elite, high, medium, or low, then identify where improvement is needed. section 2.4.5 section 2.5
