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.
Cycle Time
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.
Coding Time
What it means if it's low?
Short Coding Time represents less context switching by developers, small PR size and clear requirements and great architecture.
What it means if it's high?
Longer coding time relates to committing large chunks of code which could lead to a higher blast radius on production issues, longer review cycles, or sometimes even misses the review process due to fatigue.
Review Time
What it means if it's low?
Low Review Time represents a 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?
High review time represents limited reviewers in the team, overy occupied senior engineers not finding time to do code reviews, slows down the cycle times.
Pickup Time
What it means if it's low?
Low Pickup Time represents that as soon as the PRs are opened it is being picked for review.
What it means if it's high?
Longer pickup time represents that it is taking longer for a PR to be review, it shows that reviewers are not fiinding time
Rework Rate
What it means if it's low?
Low rework means the changes to code aren't done after the initial work which indicates that the developers are pushing high quality code the first time.
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.
Refactor Rate (Maintenance)
What it means if it's low?
Less maintenance means when engineers are writing a very well maintainable piece of code as the team continues to build new features.
What it means if it's high?
Higher maintenace represents longer time to build new features, or testing fatigue. When maintenance is high, usually estimates are off as it's hard to account for maintenance during estimates.
PR > 400 LoC
What it means if it's low?
This is a great pattern for engineers to keep PRs smaller, which can move things faster in the pipeline.
What it means if it's high?
PRs > 400 LoC takes longer to review, harder to rollback, can cause more merge conflict issues.
Unreviewed PRs
What it means if it's low?
Reviewing every PR saves a lot of post production issues and can keep higher quality across.
What it means if it's high?
Merging PRs without review is a symptom of production issue or poor quality code that could lead to higher maintenace issues in the future. Also junior engineers miss out on the learning opportunities.
Change Fail Rate/Hotfixes
What it means if it's low?
Low change failure rate represents good quality of work being delivered to end users.
What it means if it's high?
High Change Failure Rate means your teams don't have enough of a handle on testing (or) that they have an inefficient (or) error-prone development process. High change failure rate could impact customer NPS.
MTTR (Mean Time to Repair)
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 not quick to respond to Production Issues, and the end users are left dealing with system downtime/outages for a longer than desired time. This will ultimate impact Product Usage, Customer Trust, and Customer NPS.
Merge Time
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.
New Work
What it means if it's low?
Low New Work indicates the team is trying to change old code even to build new features which will impact high blast radius and poor SOLID principles implementation. 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 best SOLID practices are in place and the team can go ship new features at a faster pace as code is isolated
PR Size
What it means if it's low?
Below 100 LOC, would definitely improve code quality, code review communication, and fewer merge conflicts. Assuming the team is not pushed or evaluated on the number of PRs released in a day.
What it means if it's high?
High PR Size would result in a delayed review, decreased review quality, a large potential for errors, and expensive in both money and opportunity cost.
Deployment Frequency
What it means if it's low?
Too low Deployment frequency indicates that there maybe inefficient Devops processes, bottle necks in review or requirements and teams are delivering features at a slower pace.
What it means if it's high?
High deployment frequency shows that your team can quickly provide value and react to feedback or changes.
Active days
What it means if it's low?
When Active days are below 2 days, it usually is an indicator of unclear requirements that are changing frequently, lack of understanding around dependencies between different projects, slower clarity on, or creation, or approval on development architectures
What it means if it's high?
Active days above 5 days would mean the developers in the team are overworked and may be walking towards exhaustion or worse, burn-out.
Flashy Reviews
What it means if it's low?
Low Flashy PRs represents, Good amount of time is spent whlie Reviewing Code
What it means if it's high?
Very High Flashy PRs represent, not enough time spent to do the review. Thus impacting the quality of code and may increase in the number of bugs
