/
Metrics Glossary
Metrics Glossary
- 1 Code
- 1.1 Understanding how the code base has changed over time and where those changes are coming from
- 1.1.1 Branches: Active Branches = Active Development Efforts
- 1.1.2 Code Categorization: Code categorization can track development effort, help understand focus, normalize productivity, and keep the team(s) aligned.
- 1.1.3 Code Changes: Codebase contributions and removals can provide insights into positive refactoring and contributor seniority.
- 1.1.4 Code Duplication: Reveals Code Reusability
- 1.1.5 Commits: Commits is a volume metric which helps you understand your team's work output. While this doesn't capture everything your team does, it is a good way to identify employees that may be struggling
- 1.1.6 Commits by File Type: A codebase can consist of many different technologies or programming languages. Keeping track of the balance can be hard as your product evolves over time. Looking at the new code added by file type can help you understand what skills are needed moving forward for your team.
- 1.1.7 Commit by Pull Request: Some features are very large, and touch a lot of code. Those tend to be the riskiest, since there is such a large volume of changes. Keeping track of the scale of feature pull requests can help plan for risks
- 1.1 Understanding how the code base has changed over time and where those changes are coming from
- 2 Code Review:
- 2.1 An indicator of code quality is whether new code and features are peer-reviewed. These metrics can be used to spot risky code and processes.
- 2.1.1 Merged Pull Requests: Understanding who is merging Pull Requests will help you understand the distribution of work.
- 2.1.2 Pull Request Approvals: Permission to merge code changes after review
- 2.1.3 Pull Request Comments: One indicator of code quality is if new code and features are peer-reviewed. Having other engineers review the code and add comments helps increase confidence in the codebase and ensure the code is easily understood by others. Looking at approvals on Pull Requests can help visualize this.
- 2.1.4 Pull Request Creations: Initiating changes for review and integration into the codebase
- 2.1.5 Pull Request Cycle Time: Evaluate your engineering teams' productivity by tracking the amount of time work starts development to the time it's deployed to production.
- 2.1.6 Pull Request Response Time: The time taken to review and respond to PR’s
- 2.1.7 Pull Request Size: The size of a Pull Request can be an indicator of quality and risk if too large. Use this metric to spot risky code and prevent an increase in bugs created.
- 2.1.8 Pull Requests: Code Review and Collaboration Process
- 2.1 An indicator of code quality is whether new code and features are peer-reviewed. These metrics can be used to spot risky code and processes.
- 3 Builds
- 3.1 These build metrics are indicators of developer productivity and code quality based on the average time a build takes and the success rate by developer so you can easily spot risks and areas of improvement.
- 3.1.1 Build Success Rate: Managing features by branches leads to a cleaner, well-maintained code. Looking at how the users are following standards will identify risks in your code and areas for developers to improve.
- 3.1.2 Build Time: The average amount of time that it takes a build to complete. Long build times can cause delays in developer activity and impact productivity.
- 3.1 These build metrics are indicators of developer productivity and code quality based on the average time a build takes and the success rate by developer so you can easily spot risks and areas of improvement.
- 4 Process Health
- 4.1 These metrics give you an understanding of how work is progressing and identify areas of risks and bottlenecks so you can more confidently predict when work will be completed.
- 4.1.1 Burndown; The burndown chart helps you visualize how much work and what kind of work is left within a particular project so you can determine when the work will be done or where your team may need additional support.
- 4.1.2 Committed vs. Completed: This metric gives you an idea of how your sprint is progressing. It shows items committed at the start of the sprint, items added after the sprint started, items incomplete and completed during the spring. Understanding if your team is over or under-committing helps you plan better.
- 4.1.3 Cycle Time: How long have issues been in progress can help you resolve problems by identifying places where your team may need additional support.
- 4.1 These metrics give you an understanding of how work is progressing and identify areas of risks and bottlenecks so you can more confidently predict when work will be completed.