Engineering Metrics
Last updated onBelow are various metrics are useful in improving the team’s success…
Beware of falling into the [[metrics trap]] - these are nice to look at and can help spot problems but taking them too seriously will just the team to game the numbers which will turn counterproductive very fast. So take these numbers with a grain of salt… Additionally, I would use them based on need, for a limited time only.
PR Lead Time
This is the time between when a PR is opened and when it is merged. This data is useful for assessing team effectiveness:
- Are PRs taken seriously and reviewed in a timely manner?
- Do Developers submit PRs too early or half baked and take many cycles to get up to standard?
- Are new \ junior team members improving by gradually being able to go through the process faster?
Ideally we’d want to keep the number and duration of cycles down. New team members will probably take more time and cycles to get PRs merged asnd will gradually improve on those metrics and they’re onboarded and gain experience with both the codebase and the team’s standards.
To answer the above its important to look at these over time (at a team and member level):
- PR Avg. Lead Time
- PR Avg. number of comments
- PR number of cycles
- Avg. Cycle time