Skip to content

DORA Metrics for Platform Initiatives: CNPA practice questions

DORA (DevOps Research and Assessment) publishes the most widely used metrics for software delivery performance. The CNCF Platforms White Paper points to them as the way to measure a platform's effect on product and feature delivery, and DORA's own platform guidance asks platform teams to use them for their own performance while exposing them to application teams.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What DORA Metrics for Platform Initiatives covers in CNPA

DORA (DevOps Research and Assessment) publishes the most widely used metrics for software delivery performance. The CNCF Platforms White Paper points to them as the way to measure a platform's effect on product and feature delivery, and DORA's own platform guidance asks platform teams to use them for their own performance while exposing them to application teams. Knowing the current definitions matters, because they have changed over time.

DORA now describes five metrics in two groups. Throughput measures how many changes can move through the system over a period. Change lead time is the time it takes for a change to go from committed to version control to deployed in production. Deployment frequency is the number of deployments over a given period, or the time between deployments. Failed deployment recovery time is the time it takes to recover from a deployment that fails and requires immediate intervention. Instability measures how well deployments go. Change fail rate is the ratio of deployments that require immediate intervention, likely a rollback or a hotfix. Deployment rework rate is the ratio of deployments that are unplanned and happen as a result of an incident in production. The original four keys measured time to restore service, which DORA has replaced with failed deployment recovery time, and did not include rework rate; older material, including the white paper, still lists four metrics.

Two research findings recur. Speed and stability are not trade-offs: for most teams the metrics are correlated, and top performers do well on all five. And the metrics act as leading indicators for organizational performance and employee well-being while being lagging indicators of development and delivery practices, which is why DORA pairs them with its catalog of capabilities.

DORA lists pitfalls that are easy to turn into questions: setting the metrics as goals and ignoring Goodhart's law; relying on one metric instead of several with healthy tension between them; using a regulated industry as a shield against improving; comparing very different applications, since the metrics are meant to be applied per application or service; siloed ownership instead of sharing the metrics across development, operations and release teams; competing with other teams; and spending more on precise measurement than on improvement. Its suggested starting point is a baseline with the DORA Quick Check, a conversation about friction in the delivery process and a team commitment to improve the biggest constraint, with smaller batch sizes as a common lever.

For platform initiatives, the metrics show whether golden paths actually shorten lead time and reduce failed changes for the teams that adopt them. Comparing one team before and after it adopts a platform capability is more meaningful than comparing teams with each other.

Misconceptions include treating deployment frequency alone as proof of success, blending metrics across a whole organization, and using them to rank individuals.

At associate level, expect to define each metric, sort them into throughput and instability, recognize the newer names, and spot a misuse.

Key points

  • Throughput: change lead time, deployment frequency, failed deployment recovery time.
  • Instability: change fail rate and deployment rework rate.
  • Failed deployment recovery time replaced the older time-to-restore measure.
  • Apply the metrics per application or service and never as targets for individuals.

Three sample questions

8 CNPA questions on DORA Metrics for Platform Initiatives, 8 with explanations. How practice works

Question 1

How does DORA define change lead time?
  1. A.From a failed deployment until the service has fully recovered again
  2. B.From a feature request until development of the feature starts
  3. C.The number of deployments to production in a given period
  4. D.From commit to version control until the change is deployed in production

Correct answer: D

DORA's software delivery metrics define change lead time as the amount of time it takes for a change to go from committed to version control to deployed in production. Why the other options are wrong. "From a failed deployment until the service has fully recovered again": That is failed deployment recovery time. "From a feature request until development of the feature starts": DORA's metric starts at the commit, not at the request. "The number of deployments to production in a given period": That is deployment frequency.

Sources: CNCF CNPA curriculum (CNPA_Curriculum.pdf), DORA: Software delivery performance metrics

Question 2

DORA groups its five software delivery performance metrics into throughput and instability. Which TWO measure instability? (Select TWO.)

Select all that apply.

  1. A.Deployment rework rate
  2. B.Failed deployment recovery time
  3. C.Change fail rate
  4. D.Deployment frequency

Correct answers: A, C

DORA's metrics guide measures instability with change fail rate (the ratio of deployments that need immediate intervention) and deployment rework rate (the ratio of unplanned deployments that happen because of a production incident). Throughput is measured with change lead time, deployment frequency and failed deployment recovery time. Why the other options are wrong. "Failed deployment recovery time": DORA's current guide lists failed deployment recovery time under throughput. "Deployment frequency": DORA counts deployment frequency as a throughput metric.

Sources: CNCF CNPA curriculum (CNPA_Curriculum.pdf), DORA: Software delivery performance metrics

Question 3

A director wants one dashboard that compares the DORA metrics of the company's mobile app with those of its mainframe billing system and ranks the teams. What does DORA's metrics guide say about this?
  1. A.It is fine as long as the dashboard shows only deployment frequency, which is comparable everywhere.
  2. B.It is required, because DORA metrics must be blended into one figure across the whole organization.
  3. C.Use them per application in its own context; unlike systems should not be compared or ranked.
  4. D.It is the recommended use, because the metrics are mainly useful for ranking teams against each other.

Correct answer: C

DORA's guide says the metrics are best suited to measuring one application or service at a time and that context matters; it lists making disparate comparisons (for example a mobile app and a mainframe system) and competing against other teams as pitfalls. Why the other options are wrong. "It is fine as long as the dashboard shows ...": Using a single metric is another pitfall DORA lists ("one metric to rule them all"). "It is required, because DORA metrics must be blended ...": DORA warns that blending metrics across teams or the organization can be problematic. "It is the recommended use, because the metrics are ...": DORA says the goal is to improve a team's own performance over time, not to compete.

Sources: CNCF CNPA curriculum (CNPA_Curriculum.pdf), DORA: Software delivery performance metrics

Practice this topic

Focus mode keeps every question on DORA Metrics for Platform Initiatives until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CNPA practice across all topics.

Sources

The explanation above was checked against these official documents.