# Engineering Benchmarks

Engineering Benchmarks define how engineering performance is evaluated, compared, and improved within Oobeya.

They provide a shared reference for **best practices**, **areas that need focus**, and **risk zones** across the software development lifecycle.

This page explains:

* How benchmarks work
* How performance levels are interpreted
* Which metrics are benchmarked, and how they are grouped.

***

### What are Engineering Benchmarks?

Engineering Benchmarks are standardized performance thresholds applied to key engineering metrics in Oobeya.

They help organizations:

* Compare teams fairly within a league
* Identify improvement opportunities early
* Create a shared language between engineering teams and leadership
* Power gamification, insights, and AI-driven recommendations

Benchmarks are designed to **highlight patterns and risks**, not to enforce rigid targets.

***

### Performance Levels

Each benchmarked metric is evaluated using **three performance levels**.

#### 🏆 Elite

* Best-in-class performance
* Healthy, scalable, and sustainable engineering practices
* Serves as a benchmark for other teams

#### ⚠️ Needs Focus

* Acceptable performance with clear improvement potential
* Early signals of inefficiency or hidden risk
* Often the highest ROI area for improvement

#### 🚨 At Risk

* Below expected performance levels
* Indicates delivery, quality, reliability, or cost risk
* Requires immediate attention

***

### Benchmark Categories

Benchmarks are grouped into the following categories:

* **Project Management**
* **Development**
* **Code Review**
* **Delivery (DORA)**
* **Code Quality**
* **Application Performance**

***

#### Project Management

<table><thead><tr><th width="331.15557861328125">Metric</th><th>Elite</th><th>Needs Focus</th><th>At Risk</th></tr></thead><tbody><tr><td>Actual Reaction Time</td><td>&#x3C; 5 days</td><td>5–10 days</td><td>> 10 days</td></tr><tr><td>Cycle Time</td><td>&#x3C; 3 days</td><td>3–10 days</td><td>> 10 days</td></tr><tr><td>Lead Time</td><td>&#x3C; 7 days</td><td>7–14 days</td><td>> 14 days</td></tr><tr><td>Productivity</td><td>> 150%</td><td>100–150%</td><td>&#x3C; 100%</td></tr><tr><td>Predictability</td><td>> 90%</td><td>70–90%</td><td>&#x3C; 70%</td></tr><tr><td>Innovation Rate</td><td>> 75%</td><td>60–75%</td><td>&#x3C; 60%</td></tr></tbody></table>

#### Development

<table><thead><tr><th width="327.9208984375">Metric</th><th>Elite</th><th>Needs Focus</th><th>At Risk</th></tr></thead><tbody><tr><td>Coding Efficiency</td><td>> 98%</td><td>90–98%</td><td>&#x3C; 90%</td></tr><tr><td>Rework Rate</td><td>&#x3C; 2%</td><td>2–10%</td><td>> 10%</td></tr><tr><td>Coding Days per Week</td><td>≥ 5 days</td><td>3–5 days</td><td>&#x3C; 3 days</td></tr></tbody></table>

#### Code Review

<table><thead><tr><th width="328.09375">Metric</th><th>Elite</th><th>Needs Focus</th><th>At Risk</th></tr></thead><tbody><tr><td>Code Review Cycle Time</td><td>&#x3C; 1 day</td><td>1–7 days</td><td>> 7 days</td></tr><tr><td>Time to Merge</td><td>&#x3C; 3 days</td><td>3–30 days</td><td>> 30 days</td></tr></tbody></table>

#### Delivery (DORA)

<table><thead><tr><th width="327.017578125">Metric</th><th>Elite</th><th>Needs Focus</th><th>At Risk</th></tr></thead><tbody><tr><td>Lead Time for Changes</td><td>&#x3C; 1 day</td><td>1–30 days</td><td>> 30 days</td></tr><tr><td>Deployment Frequency</td><td>Daily</td><td>Monthly or more</td><td>Less than monthly</td></tr><tr><td>Time to Restore Service</td><td>&#x3C; 1 day</td><td>1–30 days</td><td>> 30 days</td></tr><tr><td>Change Failure Rate</td><td>&#x3C; 15%</td><td>15–30%</td><td>> 30%</td></tr></tbody></table>

#### Code Quality

<table><thead><tr><th width="328.1072998046875">Metric</th><th>Elite</th><th>Needs Focus</th><th>At Risk</th></tr></thead><tbody><tr><td>Technical Debt (New Period)</td><td>&#x3C; 3 days</td><td>3–30 days</td><td>> 30 days</td></tr><tr><td>Test Coverage (New Period)</td><td>> 80%</td><td>60–80%</td><td>&#x3C; 60%</td></tr><tr><td>Security Severity Blocker (Overall)</td><td>0 issues</td><td>1–5 issues</td><td>> 5 issues</td></tr><tr><td>Security Severity High (Overall)</td><td>0 issues</td><td>1–5 issues</td><td>> 5 issues</td></tr><tr><td>Security Severity Blocker (New Period)</td><td>0 issues</td><td>1–5 issues</td><td>> 5 issues</td></tr><tr><td>Security Severity High (New Period)</td><td>0 issues</td><td>1–5 issues</td><td>> 5 issues</td></tr><tr><td>Security Score (Overall)</td><td>A</td><td>B–C</td><td>D–E</td></tr><tr><td>Reliability Score (Overall)</td><td>A</td><td>B–C</td><td>D–E</td></tr><tr><td>Maintainability Score (Overall)</td><td>A</td><td>B–C</td><td>D–E</td></tr></tbody></table>

#### App Performance

<table><thead><tr><th width="327.80059814453125">Metric</th><th>Elite</th><th>Needs Focus</th><th>At Risk</th></tr></thead><tbody><tr><td>APDEX Score</td><td>> 0.85</td><td>0.70–0.85</td><td>&#x3C; 0.70</td></tr><tr><td>Error Rate</td><td>&#x3C; 1%</td><td>1–5%</td><td>> 5%</td></tr><tr><td>Avg. Response Time</td><td>&#x3C; 300 ms</td><td>300–1000 ms</td><td>> 1000 ms</td></tr></tbody></table>

***

### How to Use Engineering Benchmarks

Engineering Benchmarks are most effective when used to:

* Detect risks **early**
* Guide conversations instead of enforcing targets
* Trigger insights and AI-driven recommendations.

Always interpret benchmarks in context, considering:

* Team maturity
* Product complexity
* Organizational constraints.

***

### Related Topics

* [Gamification for Engineering KPIs](https://docs.oobeya.io/use-cases/gamification-for-engineering-kpis)
* AI Coach Insights
* [Engineering Metrics List](https://docs.oobeya.io/getting-started/metrics)
* [Delivery & DORA Metrics](https://docs.oobeya.io/deployment-analytics/dora-metrics-introduction)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.oobeya.io/team-insights-and-symptoms/engineering-benchmarks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.