Metrics Definitions
Comprehensive definitions for all engineering metrics used in the platform
Overall Score Metrics
Overall Score
Overall Score is a composite score that measures overall development performance by combining speed, quality, throughput, and collaboration metrics.
Overall Score = (25% × Speed) + (40% × Throughput) + (15% × Quality) + (20% × Collaboration)Speed
Speed measures the time taken to complete development tasks. It ensures efficient and predictable development cycles.
Speed Score = (50% × Cycle Time) + (25% × Cycle Time Variance) + (25% × Coding Time)To improve speed: • Keep PRs small and focused • Implement automated code reviews • Set up clear PR review guidelines • Monitor and reduce bottlenecks in PR cycle
Quality
Quality measures code review effectiveness, PR size management, and post-merge stability. It ensures maintainable code through proper review processes.
Quality Score = (30% × Unreviewed PRs) + (30% × PR Size) + (40% × Post-PR Commits)To improve quality: • Enforce code review policies • Keep PR size under 200-400 lines • Implement automated testing • Review code before merging
Throughput
Throughput quantifies team productivity by measuring PR creation rate, successful merges, and coding consistency.
Throughput Score = (50% × PR Creation Rate) + (20% × Merge Rate) + (20% × Coding Days) + (10% × Lines of Code Changes)To improve throughput: • Maintain consistent coding schedule • Break down large tasks • Monitor and improve merge success rate • Balance workload across team
Collaboration
Collaboration measures team interaction quality through PR review participation, response times, and review thoroughness.
Collaboration Score = (40% × Time to First Comment) + (20% × PRs Reviewed) + (40% × Comments per PR)To improve collaboration: • Set PR review SLAs • Encourage detailed code reviews • Implement pair programming • Regular team code reviews
Individual Metrics
Cycle Time
Total time from PR creation to merge. Measures end-to-end delivery speed, including review cycles and iteration time. A key indicator of your team's ability to deliver changes efficiently.
Time from first commit to PR merge, including all review cycles and iterations.Coding Time
Active development time spent on PRs. Measures how long developers spend implementing changes, indicating task complexity and implementation efficiency.
Time between first commit and PR creation, measuring active development effort.Cycle Time Variance
Gap between 75th percentile and 50th percentile of cycle time. Measures consistency and predictability in delivery timelines.
Difference between 75th percentile and 50th percentile of cycle time.Unreviewed PRs Merged
PRs merged without proper review. Critical quality indicator that measures adherence to code review policies.
Count of PRs merged without any review comments or approvals from team members.PR Size
Number of lines changed per PR. Large PRs are harder to review effectively and increase risk of bugs.
Total lines added + lines deleted in each PR.Time to First Comment
Time between PR creation and first review comment. Measures initial review responsiveness and team engagement.
Time elapsed between PR creation and the first review comment from any team member.Created PR Throughput
Number of new PRs created. Measures team's feature delivery pace and development momentum.
Count of new PRs created within the selected time period.Merge Rate
Percentage of PRs successfully merged versus created. Indicates work completion efficiency and quality of initial submissions.
(Number of PRs merged / Number of PRs created) × 100% within the selected time period.Coding Days
Number of days with active development per week. Measures consistent engagement and development patterns.
Count of unique days with commit activity within the selected time period.PRs Reviewed
Number of PRs reviewed by each team member. Measures review participation balance and knowledge sharing.
Count of unique PRs where a team member provided comments or approvals.Comment Count per PR
Average number of review comments per PR. Indicates review depth and discussion quality.
Total number of review comments / the total number of PRs in the selected time period.Stale PRs
PRs that remain unchanged for an extended period (Industry average is 5+ days). Identifies blocked work, forgotten PRs, or process bottlenecks.
Count of PRs with no activity based on your organisation configurations that are still open.DORA Metrics
Deployment Frequency
Deployment Frequency measures how often an organization successfully releases code to production. It indicates the team's ability to deliver value continuously.
Deployment Frequency = Total Deployments / (Number of Active Repositories × Time Period)Lead Time to Change
Lead Time for Changes measures the time from code committed to code successfully running in production. It represents the speed of delivery.
Lead Time = Production Deployment Time - First Commit TimeChange Failure Rate
Change Failure Rate measures the percentage of deployments causing a failure in production. It indicates the quality and stability of releases.
Change Failure Rate = (Failed Deployments / Total Deployments) × 100%Mean Time to Recovery
Mean Time to Recovery measures how long it takes to recover from a failure in production. It indicates the team's ability to restore service when failures occur.
MTTR = Total Recovery Time / Number of IncidentsJIRA Metrics
JIRA Metrics provide comprehensive insights into project management effectiveness, delivery performance, and team health through ticket-based analysis.
Quality Metrics
Internal bugs, external bugs, and rework metrics.
Internal Bugs
Number of bugs found internally before release to customers.
External Bugs
Number of bugs reported by customers or external users.
Rework
Tickets that were re-opened.
Velocity & Lead Time
Time taken by 75% of your tickets.
Lead Time
Time taken from when a ticket is created to when it is completed.
Hygiene Issues
Tickets with missing story points, due dates, or original estimates.
Missing Story Points
Percentage of tickets without story point estimates.
Missing Due Dates
Percentage of tickets without due dates.
Missing Original Estimates
Percentage of tickets without original time estimates.
Health Warnings
Blocked, at risk, stale, and scope creep issues.
Blocked Issues
Number of tickets currently blocked and unable to progress.
At Risk Issues
High priority tickets that are stale for more than 3 days.
Stale Issues
Tickets that have not moved in the last 3 days.
Scope Creep
Tickets that were added in middle of the sprint or release.
Understanding Percentiles
Percentiles help understand the distribution of your metrics by showing the value below which a given percentage of observations fall. For example:
Common Percentiles Used:
- 75th Percentile (P75): 75% of values fall below this point. Used for most metrics like Cycle Time and PR Size to capture typical performance while excluding extreme outliers.
- 90th/95th/99th Percentiles: Higher percentiles show worst-case scenarios. Useful for identifying problematic patterns.
- 50th Percentile (Median): The middle value, giving a balanced view of typical performance.
Usage in Metrics:
- Most metrics use P75 to capture typical performance
- Variance calculations use P75 - P50 difference
- Higher percentiles help identify problem areas
Note: Changing the percentile filter affects how metrics are calculated, helping you focus on either typical performance (lower percentiles) or potential problem areas (higher percentiles).