Docs
💯 Metrics

Metrics

  • Active Contributors: Active Contributors is the count of active users who committed code in the selected time period.

  • Active Reviewer: Active Reviewers is the count of active users who reviewed a PR in the selected time period.

  • Avg. Daily Maker Time: Average time available to a user each day to focus on building software

  • Avg. Daily Meeting Time: Average time spent by a user in scheduled & unscheduled meetings. Meeting participation data is considered for scheduled & unscheduled online meetings.

  • Bugs Resolved: Total count of issue type Bugs resolved in the selected time period. The definition of Bug is mapped to your underlying Issue tracking tool (Jira, Linear, ClickUp etc).

  • Bugs Resolved Per Member: Count of bugs resolved per active member in the team. The definition of Bug is mapped to your underlying Issue tracking tool (Jira, Linear, ClickUp etc). For teams, this is an average metric, for individuals the Bugs resolved & Bugs Resolved Per Member have the same value

  • Change Failure Rate: Change Failure Rate is the percentage of deployments that cause a failure in production. Note that this is not a measure of deployments failures, but changes that cause the application for fail.

  • Code Churn: Is the percentage of code that is replaced by the author of the code within 3 weeks of merge. High churn impacts Efficiency & captures churning of the code base. Some level of churn is normal and should be expected.

  • Coding Days: Coding days metric is defined as the number of working days that engineers have spent doing commits.

  • Coding Time: Coding time is the span of elapsed time from the first commit on a branch until a pull request is created for that branch. This metric is computed for all branches, regardless of what was the source branch

  • Comment count per PR: This metric gives an overview of the number of comments left on PRs on an average.

  • Commits: Commits represents the numbers of commits done. For teams & individuals, this is a sum of commits done to any remote Git branch. Commits done to local Git branches are not counted

  • Commits Per Contributor: Count of Git commits done per contributor

  • Cycle Time: Time taken for a pull request from First commit until it is Deployed into production. If Deployment information is unavailable, the Cycle Time is computed from first commit until the pull request is Merged. Note that any Local branches on the developer’s local git repository are not included in this computation.

  • Deployment Frequency Ratio of total deployments completed in the Production environment to the number of days in the selected date range.

  • Deploy Time Time it takes from PR merge to Production deployment. The production deployment data is retrieved only if DORA metrics are configured for the corresponding repository.

  • Code Efficiency: Efficiency is measured in percentage is the difference between total lines of code merged minus churned lines of code divided by total lines of code. High churn rate lead to a decrease in efficiency

  • Epics Resolved: Count of issue type Epic resolved in the selected time period. The definition of Epic is mapped to the underlying issue tracking tools (Jira, Linear, Clickup etc)

  • Epics Resolved Per Member: Count of epic resolved per active member in the team. The definition of Epic is mapped to the underlying issue tracking tools (Jira, Linear, Clickup etc). For teams, this is an average metric, for individuals the Epics resolved & Epics Resolved Per Member have the same value

  • Help others (code): Is the percentage of code that is replaced by an engineer other than the author within 3 weeks of merge. Changes made by the same author within 3 weeks or merge are counted under Churn

  • Interview Time: Interview time is the time spent by active members in 1:1 meetings with participants from outside of the organisation. Interviews are recognised by the word “interview” in the Calendar or Video subject or description field

  • Review Involvement: Percentage of team members involved in PR reviews. A high involvement percentage (>80%) is indicative of a self-sufficient team where majority of the team knows the code base. For teams with new members or a designated reviewer, the involvement metric would be lower.

  • Issues Resolved: Count of issues resolved in the selected time period. The definition of an Issue is mapped to all underlying issues ie. Bug, Epic, Story, Task etc. in the issue tracking tool (Jira, Linear, Clickup etc)

  • Issues Resolved Per Member: Count of issues resolved per active member in the team. The definition of an Issue is mapped to all underlying issues ie. Bug, Epic, Story, Task etc. in the issue tracking tool (Jira, Linear, Clickup etc). For teams, this is an average metric, for individuals the Epics resolved & Epics Resolved Per Member have the same value

  • Lines of Code (LoC): Total Lines of Code (LOC) changed and is the sum of LOC added and LOC deleted in the selected time period. This number is computed for each active user

  • LoC (Additions): Total Lines of Code added in the selected time period. This number is computed for each active user

  • LoC (Deletions): Total Lines of Code deleted in the selected time period. This number is computed for each active user

  • Maker time: Maker Time is the total amount of free time in which an engineer can focus, this is calculated as a ratio of 2-hour intervals without interruption to total working hours and is sourced from the connected calendar and virtual meetings

  • Mean time to restore (MTTR): MTTR is the elapsed time between a change failure & a fix to the failure that restores the application to normalcy in production.

  • Pickup Time: Pickup time is the span of elapsed time from the pull request being created until the first comment or approval or request for changes. This metric is computed for all Pull requests, regardless of what was the source branch.

  • PRs Created Per Contributor: Number of Pull requests created for each active contributor. For teams, this is an average metric and for individuals this is an absolute count

  • PRs Merged: Count of Pull requests merged for each active contributor. For teams, this is an average metric and for individuals this is an absolute count

  • PRs Merged Per Contributor: Average number of Pull requests merged for each active contributor. For teams, this is an average metric and for individuals this is an absolute count

  • PRs Opened Throughput: Count of Pull requests created for each active contributor. For teams & individuals, this is an absolute count.

  • PRs Reviewed Per Contributor: Number of Pull requests reviewed by each active contributor. For teams, this is an average metric and for individuals this is an absolute count

  • PR Size: Average number of lines of code changed (added plus removed) in a single pull request. This is an average for teams & individuals

  • Quiet Days: Quite Days are days having no significant work outside work hours. Significant work is defined as >10m of meetings, >0 PR reviews & >0 PR updates. For teams, this metric represents the percentage of team members who have Highly quiet days in the selected time period. For individuals, this metric represents the percentage of days that are Highly quiet

  • Review Time: Review time is the elapsed time between PR creation and getting the first review. First review can be comments, approval or request for changes

  • Story Points Completed: Story points completed is the sum of story points across all issues that are marked Done in the time period selected.

  • Story Points Completed Per Member: Story points completed per member is the ratio of Story points completed in the time period selected to the number of member in the selected team. For teams, this is an average metric and for individuals this is an absolute count.

  • Unreviewed PRs Merged: Unreviewed PRs Merged is the number of pull requests that were merged without any review activity.

Starred DashboardsActive Contributors