Key Industry Benchmarking Metrics:
A Comprehensive Glossary

Explore Hivel's detailed glossary of key software engineering benchmarking metrics, designed to help you understand and measure your team's performance against industry standards. This resource provides clear definitions and practical insights into each metric, enabling you to drive continuous improvement and achieve excellence in your software development processes.

Metrics

Elite

High

Medium

Low

Cycle Time
The amount of time it takes from the first commit to PR merged.
Read More

What it means if it's low?

The release process is slow leading to longer customer wait times, and could affect the product's competitiveness.

What it means if it's high?

A smooth delivery system in place, allowing for rapid progress and quick resolution of production issues, ideal for teams trying new ideas.

< 48

hrs

49-118

hrs

119-209

hrs

210+

hrs

Coding Time
The time it takes from the first commit until a PR is open.
Read More

What it means if it's low?

Less context switching by developers, small PR size, clear requirements and great architecture.

What it means if it's high?

Committing large chunks of code can slow down coding. It can lead to higher blast radius on production issues or longer review cycles.

< 12

hrs

12-24

hrs

24-38

hrs

39+

hrs

Review Time
The time it takes a PR to be reviewed since it's Open.
Read More

What it means if it's low?

Highly collaborative team dynamics, reviewers moving things at a faster pace and delivering features to customers with higher quality.

What it means if it's high?

Limited reviewers in the team, or overly occupied senior engineers not finding time to do code reviews.

< 6

hrs

6-13

hrs

13-28

hrs

29+

hrs

Deployment Time
The average time between PR reviewed to PR merged.
Read More

What it means if it's low?

Low deployment time correlates to efficient CI/CD processes

What it means if it's high?

Longer deployment times represent CI/CD issues, delaying the release process.

< 1

hrs

< 2

hrs

2-7

hrs

8+

hrs

Rework
The amount of changes made to code that is less than 30 days old.
Read More

What it means if it's low?

Developers strive to deliver high-quality code on the first attempt, minimizing the need for subsequent changes.

What it means if it's high?

High rework rates are caused by PR feedback, QA feedback or an engineer trying to improve the code after committing.

5-10

%

10-15

%

15-20

%

20+

%

Maintenance
New lines of code modified that were written before the last 30 days.
Read More

What it means if it's low?

Engineers are writing well-maintainable pieces of code as the team continues to build new features.

What it means if it's high?

Longer time to build new features, or testing fatigue. When maintenance is high, estimates are usually off.

10-15

%

15-20

%

20-25

%

25+

%

PR > 400 LoC
The Number of PRs with more than 400 LoC.
Read More

What it means if it's low?

Small PRs can move things faster in the pipeline.

What it means if it's high?

PRs > 400 LoC take longer to review, and are harder to rollback, which can cause more merge conflict issues.

0

%

< 5

%

< 20

%

20+

%

PRs merged without review
All PRs that do not have a review state.
Read More

What it means if it's low?

Reviewing every PR saves a lot of post-production issues and can maintain quality of the product.

What it means if it's high?

Merging PRs without review is a symptom of production issues or poor-quality code that could lead to higher maintenance issues in the future. Also, junior engineers miss out on learning opportunities.

10-15

%

15-20

%

20-25

%

25+

%

Change Fail Rate/Hotfixes
The total releases (PRs merged to master) that caused production issues. On Hivel, this is the number of PRs merged that have a PR label, title or branch as hot fix or such variations.
Read More

What it means if it's low?

Good quality of work is being delivered to end users.

What it means if it's high?

Teams don't have enough of a handle on testing or they have an inefficient or error-prone development process. High change failure rate could impact customer NPS.

0-15

%

16-30

%

17-45

%

46-60

%

MTTR (Mean Time to Repair)
Average time it takes for a production issue to be fixed. This is measured by the Average Cycle Time for PRs that have a label or title as 'hotfix' (or similar variations).
Read More

What it means if it's low?

Teams are quick to respond to production issues, and the end users are most likely to not endure system downtime/outages for long.

What it means if it's high?

Teams are slow to respond to production issues, and the end users are left dealing with system downtime/outages for a longer than desired time. This will ultimately impact Product Usage, Customer Trust, and Customer NPS.

1

day

1-7

days

8-15

days

> 15

days

Open PRs
If a PR is currently in active OPEN state.
*This is calculated irrespective of the time period.
Read More

What it means if it's low?

Fewer open PRs at any point in time indicates excellent DevOps culture.

What it means if it's high?

Too many open PRs can indicate an inefficient DevOps process or lengthy review times due to bottlenecks, leading to longer cycle times and spillovers.

< 7

hrs

7-12

hrs

12-18

hrs

19+

hrs

New Work
New/total lines of code of code added or modified
Read More

What it means if it's low?

The team is trying to change old code even to build new features which will impact high blast radius. It's a signal to review the architecture.

What it means if it's high?

More New Work along with slight maintenance is always a good sign, as it indicates solid practices are in place and the team can ship new features at a faster pace as the code is isolated.

> 80

%

80-60

%

40-60

%

< 40

%

PR Size
The number of code lines modified in a pull request.

*L.O.C. - Lines of Code.
Read More

What it means if it's low?

Smaller PRs are easier to review, safer to merge, and correlate to a lower Cycle Time. It also improves code quality, code review communication, and fewer merge conflicts.

What it means if it's high?

Large PRs result in delayed reviews, decreased review quality, and a large potential for errors.

> 100

LOC

100 - 225

LOC

225 - 400

LOC

400+

LOC

Deployment Frequency
Deployment Frequency is how often code is released
This is calculated by - (Total number of PRs merged to master or main in)/(Time Period)
Read More

What it means if it's low?

Inefficient Devops processes, bottlenecks in review or requirements, and team delivering features less often.

What it means if it's high?

Team can quickly provide value and react to feedback or changes, It represents a stable and healthy continuous delivery pipeline.

Daily

> 1

week

1

week

< 1

week

Active days
Average number of active days per engineer
This is calculated by - (Total number of days with any activity)/(Total number of active engineers)
*Average could be more than 5 if engineers are working on the weekend.
Read More

What it means if it's low?

Active days below 2 indicates unclear or changing requirements, dependencies, or unfamiliarity with development architectures.

What it means if it's high?

Active days above 5 mean the team is overworked and may be heading towards exhaustion or worse, burn-out.

4-5

days

3-4

days

2

days

< 2

days

Average commits
Average number of commits per day per engineer
This is calculated by - (Total Number of commits)/(Number of active engineers)
Read More

What it means if it's low?

Committing too much code at once can lead to longer code review times and potential data loss. It could also mean difficulties in translating requirements into code, causing longer cycle times.

What it means if it's high?

A high number of small commits is always a good sign. It results in less error-prone code, making reviewing and maintaining the code easier.

4-5

days

3-4

days

1

day

< 2

days

Flashy Reviews
Any PR that has a review time < 5 mins
Read More

What it means if it's low?

A good amount of time is spent while reviewing code.

What it means if it's high?

Not enough time was spent to do the review, which may impact the quality of code and increase the number of bugs.

0

%

< 5

%

< 20

%

20+

%

Cycle time > 5 days
PRs merged which had a cycle time of more than 5 days.
Read More

What it means if it's low?

Shorter cycle times indicate an optimized process, quicker time to market, and an efficient dev team.

What it means if it's high?

Longer cycle times indicate inefficiencies in the process and slower time to market. It can also lead to delivery delays for customers, lost prospects, and an unhappy, inefficient dev team.

0

%

5-10

%

10-20

%

20+

%

Cycle Time
Cycle time is the amount of time it takes from the first commit to PR merged.

Elite

<48 hrs

High

49-118 hrs

Medium

119-209 hrs

Low

210+ hrs

What it means if it's low?

Things are taking too long to release, can impact competitiveness of the product in the market, customers may be waiting too long for requests

What it means if it's high?

Very smooth delivery system in place, things are moving at a rapid pace. At this pace, even if we see production issues, things can be fixed faster, great for teams experimenting new ideas.

Cycle Time
Cycle time is the amount of time it takes from the first commit to PR merged.

Elite

<48 hrs

High

49-118 hrs

Medium

119-209 hrs

Low

210+ hrs

What it means if it's low?

Things are taking too long to release, can impact competitiveness of the product in the market, customers may be waiting too long for requests

What it means if it's high?

Very smooth delivery system in place, things are moving at a rapid pace. At this pace, even if we see production issues, things can be fixed faster, great for teams experimenting new ideas.

Heads Up!

To get the full picture, switch to a big screen.

Trust us, it's worth it!