Advanced
Engineering Metrics
#DORA-metrics
#deployment-frequency
#lead-time
#MTTR
#change-failure-rate
DORA Metrics Communication
5 exercises — master the vocabulary for discussing DORA engineering performance metrics in team reviews, executive reports, and engineering health conversations.
0 / 26 completed
1 / 26
During an engineering all-hands, the VP of Engineering says: "We track all four DORA metrics." What are the four DORA metrics, and which two are velocity metrics versus stability metrics?
DORA (DevOps Research and Assessment) metrics are the industry-standard framework for measuring engineering delivery performance, validated by research across thousands of organisations.
DORA performance tiers (2023 State of DevOps Report):
Key vocabulary:
• DORA — DevOps Research and Assessment; research org founded by Nicole Forsgren, Jez Humble, Gene Kim
• Velocity metric — measures how fast value is delivered to production
• Stability metric — measures how reliably the system operates after changes
| Metric | Category | Measures |
|---|---|---|
| Deployment Frequency | Velocity | How often code is deployed to production |
| Lead Time for Changes | Velocity | Time from commit to running in production |
| Mean Time to Restore (MTTR) | Stability | Time to restore service after an incident |
| Change Failure Rate | Stability | % of deployments causing a service degradation |
DORA performance tiers (2023 State of DevOps Report):
| Tier | Deploy Freq | Lead Time | MTTR | CFR |
|---|---|---|---|---|
| Elite | Multiple/day | <1 hour | <1 hour | <5% |
| High | 1/day–1/week | 1 day | <1 day | 5–10% |
| Medium | 1/week–1/month | 1 week–1 month | 1 day–1 week | 10–15% |
| Low | <1/month | 1–6 months | >1 week | >15% |
Key vocabulary:
• DORA — DevOps Research and Assessment; research org founded by Nicole Forsgren, Jez Humble, Gene Kim
• Velocity metric — measures how fast value is delivered to production
• Stability metric — measures how reliably the system operates after changes
2 / 26
An engineering team reports: "Our lead time for changes is 18 days." What does lead time for changes mean in DORA vocabulary, and which performance tier does 18 days place this team in?
Lead time for changes is one of the most meaningful engineering velocity metrics — it captures the entire software delivery pipeline from code commit to production.
What the clock measures exactly:
Start: the moment a developer commits code to the main branch (or opens a PR)
End: the moment that same code is serving production traffic
What contributes to long lead times:
18 days = medium performer tier:
This means code written by a developer takes over two weeks to reach users, significantly limiting the team's ability to respond to feedback, fix production bugs quickly, and iterate on features. Improvements: trunk-based development, smaller PRs, automated testing, removing manual deployment gates.
Key vocabulary:
• Lead time for changes — time from code commit to running in production
• Trunk-based development — all developers commit to a single main branch; reduces merge delays
• Deployment pipeline — the automated sequence from code commit to production; bottlenecks here directly inflate lead time
What the clock measures exactly:
Start: the moment a developer commits code to the main branch (or opens a PR)
End: the moment that same code is serving production traffic
What contributes to long lead times:
| Stage | Common bottleneck |
|---|---|
| Code review | Long queue; reviewers not available; large PRs |
| CI pipeline | Slow tests; flaky gates; manual approvals |
| Staging/QA | Manual testing queues; environment availability |
| Deployment approval | Change advisory boards; scheduled deploy windows |
18 days = medium performer tier:
This means code written by a developer takes over two weeks to reach users, significantly limiting the team's ability to respond to feedback, fix production bugs quickly, and iterate on features. Improvements: trunk-based development, smaller PRs, automated testing, removing manual deployment gates.
Key vocabulary:
• Lead time for changes — time from code commit to running in production
• Trunk-based development — all developers commit to a single main branch; reduces merge delays
• Deployment pipeline — the automated sequence from code commit to production; bottlenecks here directly inflate lead time
3 / 26
A postmortem document states: "MTTR for this incident was 4 hours 23 minutes." What does MTTR measure, how is it calculated, and which DORA tier does 4h23m represent?
MTTR (Mean Time to Restore) is the primary measure of how well a team recovers from production failures — a critical indicator of operational maturity and system resilience.
Precise definition:
MTTR = Sum of all restoration times ÷ Number of incidents
Restoration time = Time from detection (alert triggered) to service restored (back to SLA-compliant behaviour)
Important distinction — MTTR vs related terms:
4h23m context:
DORA "medium" tier for MTTR: 1 day–1 week. 4h23m is actually near the high tier boundary (<1 day = high performer). Elite teams restore in under 1 hour, typically through automated rollback and feature flag disabling.
How elite teams achieve sub-1-hour MTTR:
• Automated rollback triggered by error rate spike (e.g. Argo Rollouts canary analysis)
• Feature flags for instant disabling of new functionality
• Runbooks with step-by-step recovery procedures
• Well-practiced incident response (regular game days)
Key vocabulary:
• MTTR — Mean Time to Restore; detection to full service recovery
• Rollback — automated reversal of a deployment to the previous known-good state
• Feature flag — a runtime switch enabling/disabling functionality without redeployment
Precise definition:
MTTR = Sum of all restoration times ÷ Number of incidents
Restoration time = Time from detection (alert triggered) to service restored (back to SLA-compliant behaviour)
Important distinction — MTTR vs related terms:
| Term | Measures |
|---|---|
| MTTR (Restore) | Detection → service restored to normal |
| MTTD (Detect) | Failure begins → alert triggers |
| MTTF (Failure) | Last repair → next failure |
| MTBF (Between Failures) | Average time between successive failures |
4h23m context:
DORA "medium" tier for MTTR: 1 day–1 week. 4h23m is actually near the high tier boundary (<1 day = high performer). Elite teams restore in under 1 hour, typically through automated rollback and feature flag disabling.
How elite teams achieve sub-1-hour MTTR:
• Automated rollback triggered by error rate spike (e.g. Argo Rollouts canary analysis)
• Feature flags for instant disabling of new functionality
• Runbooks with step-by-step recovery procedures
• Well-practiced incident response (regular game days)
Key vocabulary:
• MTTR — Mean Time to Restore; detection to full service recovery
• Rollback — automated reversal of a deployment to the previous known-good state
• Feature flag — a runtime switch enabling/disabling functionality without redeployment
4 / 26
A VP of Engineering asks: "Our change failure rate is 18%. What does that mean in context?" How should this metric be explained using DORA vocabulary?
Change failure rate (CFR) is the stability counterpart to deployment frequency — it tells you whether the velocity you are achieving comes at the cost of reliability.
Precise definition:
CFR = (Number of deployments causing a degraded service or requiring remediation) ÷ (Total number of deployments) × 100
What "counts" as a failure:
• Emergency hotfix deployed within hours of a release
• Rollback of a deployment due to errors or user complaints
• Incident declared as a result of a deployment
• Production patch deployed to correct a regression
DORA performance tiers for CFR:
18% = low performer; remediation actions:
• Strengthen automated testing (increase branch coverage, add integration tests)
• Implement canary or blue-green deployments to limit blast radius
• Add pre-production staging environment that mirrors production traffic patterns
• Run blameless postmortems on every failure to identify systemic causes
Key vocabulary:
• Change failure rate — % of deployments causing a degraded service requiring remediation
• Canary deployment — incremental rollout to a small percentage of traffic before full deployment
• Blameless postmortem — incident review focused on systemic causes, not individual fault
Precise definition:
CFR = (Number of deployments causing a degraded service or requiring remediation) ÷ (Total number of deployments) × 100
What "counts" as a failure:
• Emergency hotfix deployed within hours of a release
• Rollback of a deployment due to errors or user complaints
• Incident declared as a result of a deployment
• Production patch deployed to correct a regression
DORA performance tiers for CFR:
| Tier | CFR | Meaning |
|---|---|---|
| Elite | <5% | Fewer than 1 in 20 deployments causes issues |
| High | 5–10% | 1 in 10–20 deployments causes issues |
| Medium | 10–15% | 1 in 7–10 deployments causes issues |
| Low | >15% | More than 1 in 7 deployments causes issues |
18% = low performer; remediation actions:
• Strengthen automated testing (increase branch coverage, add integration tests)
• Implement canary or blue-green deployments to limit blast radius
• Add pre-production staging environment that mirrors production traffic patterns
• Run blameless postmortems on every failure to identify systemic causes
Key vocabulary:
• Change failure rate — % of deployments causing a degraded service requiring remediation
• Canary deployment — incremental rollout to a small percentage of traffic before full deployment
• Blameless postmortem — incident review focused on systemic causes, not individual fault
5 / 26
During a team health review, an engineer says: "We improved our deployment frequency from weekly to daily without any increase in our change failure rate." What is the DORA term for this pattern, and why is it significant?
This scenario illustrates the central finding of DORA research: high-performing engineering teams achieve BOTH higher velocity AND higher stability simultaneously — they are not in tension.
The "deployment frequency vs stability" paradox:
Engineering intuition often suggests: deploy more often → more risk → more failures. DORA research across 30,000+ professionals consistently disproves this:
• Elite performers deploy more frequently AND have lower change failure rates than low performers
• The key enabler is automated quality — not slower deployment cadences
What enables high frequency + high stability:
The vocabulary to describe this achievement:
• "High deployment frequency with low change failure rate" — the hallmark of elite engineering performance
• "Deployment decoupled from release" — combining frequent deployments with feature flags so production code changes and user-visible features change independently
• "Psychological safety and blameless culture" — DORA research identifies culture as a predictor of technical performance
Key vocabulary:
• DORA elite performer — team achieving high scores on all four DORA metrics simultaneously
• Deployment vs release — deploying code to production (technical) vs making a feature visible to users (business decision)
• Continuous delivery maturity — the organisational capability level enabling elite DORA performance
The "deployment frequency vs stability" paradox:
Engineering intuition often suggests: deploy more often → more risk → more failures. DORA research across 30,000+ professionals consistently disproves this:
• Elite performers deploy more frequently AND have lower change failure rates than low performers
• The key enabler is automated quality — not slower deployment cadences
What enables high frequency + high stability:
| Practice | Effect on CFR |
|---|---|
| Trunk-based development | Smaller changes = smaller blast radius |
| Comprehensive automated tests | Catches regressions before production |
| Canary / progressive delivery | Limits impact of bad deployments |
| Shift-left security | Security issues caught before merge |
The vocabulary to describe this achievement:
• "High deployment frequency with low change failure rate" — the hallmark of elite engineering performance
• "Deployment decoupled from release" — combining frequent deployments with feature flags so production code changes and user-visible features change independently
• "Psychological safety and blameless culture" — DORA research identifies culture as a predictor of technical performance
Key vocabulary:
• DORA elite performer — team achieving high scores on all four DORA metrics simultaneously
• Deployment vs release — deploying code to production (technical) vs making a feature visible to users (business decision)
• Continuous delivery maturity — the organisational capability level enabling elite DORA performance
6 / 26
PR#1234 is awaiting review. The PR description reads: 'Implemented a new feature to allow users to upload images directly to their profiles. Performance tests show a slight increase in latency for image uploads.' Sarah, the team's Reliability Engineer, replies in Slack: 'Looks good! Just make sure you're monitoring the change failure rate closely after this deployment.' What does Sarah *primarily* mean when she advises monitoring the change failure rate? Sarah is referring to the change failure rate metric as defined by DORA. This rate specifically measures the percentage of deployments that result in an incident or degrade system performance – it's a key indicator of stability. Options B and C relate to velocity and deployment frequency metrics respectively, while option D focuses on user satisfaction, which is a separate measure entirely. Monitoring this rate helps identify potential issues caused by new code changes.
7 / 26
PR#5678 is awaiting merge. The PR description reads: 'Updated the user authentication service to use a new OAuth2 provider. Initial tests show no regressions in response time.' Mark, a DevOps Engineer, comments on Slack: 'Excellent! Let's keep an eye on our deployment frequency – we want to maintain this rapid release cadence.' What is Mark *primarily* concerned about when he suggests monitoring deployment frequency in relation to this change? Mark's focus on deployment frequency reflects the DORA metric's emphasis on *lead time for changes*. A rapid release cadence (high deployment frequency) generally indicates a streamlined development process and faster delivery of value. Monitoring this metric helps assess whether the team can maintain its speed without compromising stability – a key component of overall performance within the DORA framework. The other options misinterpret Mark's comment, focusing on response time alone or assuming low-risk deployments always warrant minimal scrutiny.
8 / 26
During a sprint retrospective, the team discusses their recent performance. The Scrum Master asks: 'Let's talk about our deployment frequency. We've been deploying to production three times per week.' One developer says, 'That's great! Our change failure rate is only 2%.' Another developer responds with an API response:
{
"metric": "deployment_frequency",
"value": 3,
"unit": "per_week",
"related_metrics": ["change_failure_rate"]
}
What is the *primary* purpose of this API response in the context of DORA metrics, and what should the other developer consider alongside it?This question tests understanding of how deployment frequency relates to the broader DORA framework. The correct answer emphasizes that while frequent deployments are desirable, they must be paired with a low change failure rate to ensure stability and avoid disruptions. The other options misinterpret the value of deployment frequency or fail to recognize its interdependence with other metrics like change failure rate and lead time. The API response itself is a good example of how these metrics can be tracked and communicated.
9 / 26
PR#9123 is awaiting merge. The PR description reads: 'Implemented a new API endpoint for retrieving customer order history. Performance testing indicates an average response time of 1.5 seconds.' David, the Lead Developer, replies in Slack: 'Sounds good! Let's track our lead time to see if we can optimize this further.' What does David primarily mean when he suggests tracking lead time in relation to this change? Consider the broader DORA context.
David's suggestion to track lead time reflects DORA's focus on *how* value is delivered, not just the technical performance of a single component. Lead Time to Value (LTV) measures the time it takes for a code change to deliver business value – encompassing everything from commit to deployment and subsequent user impact. Option A incorrectly focuses solely on response time; options C and D are tangential to the core concept of lead time.
10 / 26
PR#1234 is awaiting review. The PR description reads: 'Implemented a new feature to allow users to upload images directly to their profiles. Performance tests show a slight increase in latency for image uploads.' Sarah, the team's Reliability Engineer, replies in Slack: 'Looks good! Just make sure you're monitoring the change failure rate closely after this deployment.' What does Sarah *primarily* mean when she advises monitoring the change failure rate? Sarah is referring to the change failure rate metric as defined by DORA. This rate specifically measures the percentage of deployments that result in an incident or degrade system performance – it's a key indicator of stability. Options B and C relate to velocity and deployment frequency metrics respectively, while option D focuses on user satisfaction, which is a separate measure entirely. Monitoring this rate helps identify potential issues caused by new code changes.
11 / 26
PR#5678 is awaiting merge. The PR description reads: 'Updated the user authentication service to use a new OAuth2 provider. Initial tests show no regressions in response time.' Mark, a DevOps Engineer, comments on Slack: 'Excellent! Let's keep an eye on our deployment frequency – we want to maintain this rapid release cadence.' What is Mark *primarily* concerned about when he suggests monitoring deployment frequency in relation to this change? Mark's focus on deployment frequency reflects the DORA metric's emphasis on *lead time for changes*. A rapid release cadence (high deployment frequency) generally indicates a streamlined development process and faster delivery of value. Monitoring this metric helps assess whether the team can maintain its speed without compromising stability – a key component of overall performance within the DORA framework. The other options misinterpret Mark's comment, focusing on response time alone or assuming low-risk deployments always warrant minimal scrutiny.
12 / 26
During a sprint retrospective, the team discusses their recent performance. The Scrum Master asks: 'Let's talk about our deployment frequency. We've been deploying to production three times per week.' One developer says, 'That's great! Our change failure rate is only 2%.' Another developer responds with an API response:
{
"metric": "deployment_frequency",
"value": 3,
"unit": "per_week",
"related_metrics": ["change_failure_rate"]
}
What is the *primary* purpose of this API response in the context of DORA metrics, and what should the other developer consider alongside it?This question tests understanding of how deployment frequency relates to the broader DORA framework. The correct answer emphasizes that while frequent deployments are desirable, they must be paired with a low change failure rate to ensure stability and avoid disruptions. The other options misinterpret the value of deployment frequency or fail to recognize its interdependence with other metrics like change failure rate and lead time. The API response itself is a good example of how these metrics can be tracked and communicated.
13 / 26
PR#9123 is awaiting merge. The PR description reads: 'Implemented a new API endpoint for retrieving customer order history. Performance testing indicates an average response time of 1.5 seconds.' David, the Lead Developer, replies in Slack: 'Sounds good! Let's track our lead time to see if we can optimize this further.' What does David primarily mean when he suggests tracking lead time in relation to this change? Consider the broader DORA context.
David's suggestion to track lead time reflects DORA's focus on *how* value is delivered, not just the technical performance of a single component. Lead Time to Value (LTV) measures the time it takes for a code change to deliver business value – encompassing everything from commit to deployment and subsequent user impact. Option A incorrectly focuses solely on response time; options C and D are tangential to the core concept of lead time.
14 / 26
PR#1234 is awaiting review. The PR description reads: 'Implemented a new feature to allow users to upload images directly to their profiles. Performance tests show a slight increase in latency for image uploads.' Sarah, the team's Reliability Engineer, replies in Slack: 'Looks good! Just make sure you're monitoring the change failure rate closely after this deployment.' What does Sarah *primarily* mean when she advises monitoring the change failure rate? Sarah is referring to the change failure rate metric as defined by DORA. This rate specifically measures the percentage of deployments that result in an incident or degrade system performance – it's a key indicator of stability. Options B and C relate to velocity and deployment frequency metrics respectively, while option D focuses on user satisfaction, which is a separate measure entirely. Monitoring this rate helps identify potential issues caused by new code changes.
15 / 26
PR#5678 is awaiting merge. The PR description reads: 'Updated the user authentication service to use a new OAuth2 provider. Initial tests show no regressions in response time.' Mark, a DevOps Engineer, comments on Slack: 'Excellent! Let's keep an eye on our deployment frequency – we want to maintain this rapid release cadence.' What is Mark *primarily* concerned about when he suggests monitoring deployment frequency in relation to this change? Mark's focus on deployment frequency reflects the DORA metric's emphasis on *lead time for changes*. A rapid release cadence (high deployment frequency) generally indicates a streamlined development process and faster delivery of value. Monitoring this metric helps assess whether the team can maintain its speed without compromising stability – a key component of overall performance within the DORA framework. The other options misinterpret Mark's comment, focusing on response time alone or assuming low-risk deployments always warrant minimal scrutiny.
16 / 26
During a sprint retrospective, the team discusses their recent performance. The Scrum Master asks: 'Let's talk about our deployment frequency. We've been deploying to production three times per week.' One developer says, 'That's great! Our change failure rate is only 2%.' Another developer responds with an API response:
{
"metric": "deployment_frequency",
"value": 3,
"unit": "per_week",
"related_metrics": ["change_failure_rate"]
}
What is the *primary* purpose of this API response in the context of DORA metrics, and what should the other developer consider alongside it?This question tests understanding of how deployment frequency relates to the broader DORA framework. The correct answer emphasizes that while frequent deployments are desirable, they must be paired with a low change failure rate to ensure stability and avoid disruptions. The other options misinterpret the value of deployment frequency or fail to recognize its interdependence with other metrics like change failure rate and lead time. The API response itself is a good example of how these metrics can be tracked and communicated.
17 / 26
PR#9123 is awaiting merge. The PR description reads: 'Implemented a new API endpoint for retrieving customer order history. Performance testing indicates an average response time of 1.5 seconds.' David, the Lead Developer, replies in Slack: 'Sounds good! Let's track our lead time to see if we can optimize this further.' What does David primarily mean when he suggests tracking lead time in relation to this change? Consider the broader DORA context.
David's suggestion to track lead time reflects DORA's focus on *how* value is delivered, not just the technical performance of a single component. Lead Time to Value (LTV) measures the time it takes for a code change to deliver business value – encompassing everything from commit to deployment and subsequent user impact. Option A incorrectly focuses solely on response time; options C and D are tangential to the core concept of lead time.
18 / 26
PR#1234 is awaiting review. The PR description reads: 'Implemented a new feature to allow users to upload images directly to their profiles. Performance tests show a slight increase in latency for image uploads.' Sarah, the team's Reliability Engineer, replies in Slack: 'Looks good! Just make sure you're monitoring the change failure rate closely after this deployment.' What does Sarah *primarily* mean when she advises monitoring the change failure rate? Sarah is referring to the change failure rate metric as defined by DORA. This rate specifically measures the percentage of deployments that result in an incident or degrade system performance – it's a key indicator of stability. Options B and C relate to velocity and deployment frequency metrics respectively, while option D focuses on user satisfaction, which is a separate measure entirely. Monitoring this rate helps identify potential issues caused by new code changes.
19 / 26
PR#5678 is awaiting merge. The PR description reads: 'Updated the user authentication service to use a new OAuth2 provider. Initial tests show no regressions in response time.' Mark, a DevOps Engineer, comments on Slack: 'Excellent! Let's keep an eye on our deployment frequency – we want to maintain this rapid release cadence.' What is Mark *primarily* concerned about when he suggests monitoring deployment frequency in relation to this change? Mark's focus on deployment frequency reflects the DORA metric's emphasis on *lead time for changes*. A rapid release cadence (high deployment frequency) generally indicates a streamlined development process and faster delivery of value. Monitoring this metric helps assess whether the team can maintain its speed without compromising stability – a key component of overall performance within the DORA framework. The other options misinterpret Mark's comment, focusing on response time alone or assuming low-risk deployments always warrant minimal scrutiny.
20 / 26
During a sprint retrospective, the team discusses their recent performance. The Scrum Master asks: 'Let's talk about our deployment frequency. We've been deploying to production three times per week.' One developer says, 'That's great! Our change failure rate is only 2%.' Another developer responds with an API response:
{
"metric": "deployment_frequency",
"value": 3,
"unit": "per_week",
"related_metrics": ["change_failure_rate"]
}
What is the *primary* purpose of this API response in the context of DORA metrics, and what should the other developer consider alongside it?This question tests understanding of how deployment frequency relates to the broader DORA framework. The correct answer emphasizes that while frequent deployments are desirable, they must be paired with a low change failure rate to ensure stability and avoid disruptions. The other options misinterpret the value of deployment frequency or fail to recognize its interdependence with other metrics like change failure rate and lead time. The API response itself is a good example of how these metrics can be tracked and communicated.
21 / 26
PR#9123 is awaiting merge. The PR description reads: 'Implemented a new API endpoint for retrieving customer order history. Performance testing indicates an average response time of 1.5 seconds.' David, the Lead Developer, replies in Slack: 'Sounds good! Let's track our lead time to see if we can optimize this further.' What does David primarily mean when he suggests tracking lead time in relation to this change? Consider the broader DORA context.
David's suggestion to track lead time reflects DORA's focus on *how* value is delivered, not just the technical performance of a single component. Lead Time to Value (LTV) measures the time it takes for a code change to deliver business value – encompassing everything from commit to deployment and subsequent user impact. Option A incorrectly focuses solely on response time; options C and D are tangential to the core concept of lead time.
22 / 26
During a daily standup, Alex, a Developer, reports: 'We've been consistently deploying code to production every 6 hours. This has allowed us to rapidly iterate on features.' The Engineering Manager responds, 'Let's discuss the implications of this frequency concerning our DORA metrics – specifically, cycle time. How should Alex best frame his contribution for a more data-driven discussion?'
The question assesses understanding of how to articulate a metric's impact in a technical discussion. Option A is too vague and doesn't address the core issue. Option B simply restates the deployment frequency without acknowledging its relevance to cycle time. Option C demonstrates an awareness of the connection between deployment frequency and cycle time, representing the desired response. Option D incorrectly suggests that high frequency is always optimal.
23 / 26
Reviewing a pull request for a new microservice, Emily, a Senior Developer, writes in the comments: 'Looks good! Response times are consistently under 200ms.' What is the *most* effective way for Emily to communicate this information within the context of DORA metrics and potential performance concerns?
The core issue here is framing performance data in a way that relates to broader DORA metrics. Option A focuses solely on SLAs and doesn't address the underlying performance. Option B correctly describes the metric but lacks context. Option C highlights monitoring needs, which is important, but not the primary communication strategy. Option D suggests further testing, which isn't necessarily needed after initial verification.
24 / 26
David, a DevOps Engineer, is explaining our recent deployment numbers to the team. He states: 'Our lead indicator – deployments per week – is currently at 15. We're aiming for 20.' What does David *primarily* want to convey regarding this number and its implications?
David's statement highlights the importance of lead indicators in DORA metrics. The key takeaway isn't just about hitting a target number; it's about what that number *means* for overall performance. Option A is misleading as high frequency doesn't automatically equate to efficiency. Option B correctly identifies the implication - automation opportunities. Option C is too general, and option D suggests an undesirable outcome.
25 / 26
Sarah, a Software Engineer, describes a recent change to her code in the PR description: 'Implemented a new feature that allows users to upload images. The average upload time is now 3 seconds.' What should Sarah *immediately* add to this description to better align with DORA metrics and facilitate further discussion?
This question tests understanding of how to translate performance data into actionable insights. The initial statement only presents a metric without context. Option A is a potential solution but doesn't address the immediate concern. Option B correctly identifies the problem and prompts investigation – this is what's needed. Options C and D provide insufficient context or irrelevant solutions.
26 / 26
During a Slack conversation about recent application performance, Ben, a QA Engineer, writes: 'The error rate has dropped significantly since the last deployment.' What is the *most* valuable piece of information Ben should provide to help the team understand this improvement in relation to DORA metrics?
The question focuses on interpreting performance data beyond simply stating a reduction in errors. Option A is too simplistic. Option B provides a clear connection to stability and reliability – key DORA metrics. Options C and D are appreciative but don't contribute to the technical understanding needed for informed decision-making.
Frequently Asked Questions
What does the "DORA Metrics Communication" exercise practise?
Practice English vocabulary for discussing DORA metrics: deployment frequency, lead time for changes, MTTR, and change failure rate in engineering team conversations. 5 exercises.
How many questions are in this exercise?
This exercise has 26 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Advanced. If the vocabulary feels difficult, browse the Code Quality & Metrics category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "DORA Metrics Communication" part of a larger series?
Yes — it's one exercise in the Code Quality & Metrics category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Code Quality & Metrics category page for related exercises, or browse the main Exercises hub for other IT English topics.