Validation at a metric level for BitBucket
Purpose: To validate the accuracy of key engineering productivity metrics shown in Hivel by manually cross-checking with raw data from Bitbucket for a selected developer.
Prerequisites
Access to the Bitbucket repository and Bitbucket UI with permission to view pull requests, commits, and reviews.
Access to the Hivel.ai platform with permissions to view the developer's metrics.
Basic familiarity with Bitbucket's interface (Pull Requests, Commits, and Activity tabs).
Metrics Definitions
Cycle Time
Time from first commit to PR merged.
Coding Time
Time from first commit until PR is opened.
Review Time
Time from PR opened until PR is reviewed.
PR > 400 LoC
Number of PRs with more than 400 lines of code changed.
PRs merged without review
PRs merged that have no recorded review state.
MTTR (Mean Time to Repair)
Average cycle time for production issue fixes identified by 'hotfix' label or title.
Deployment Frequency
How often code is released — number of PRs merged to main/master per time period.
Active Days
Average number of days with any activity per engineer.
Flashy Reviews
PRs that have a review time under 5 minutes.
Step-by-Step Validation Process for One Developer
Identify the Developer and Time Period
In Bitbucket, locate the developer by username or email.
Filter PRs and commits to only those authored by this developer within the validation time period.
Ensure to select a shorter time period e.g. a week or 3 days to get a limited amount of data to cross-check with BitBucket.
1. Validate Cycle Time
On Hivel: Go to Pull Request screen and filter out the team, developer, and time frame for the list of merged PRs in that duration.
Go to Cockpit to look at the average Cycle time for the same filters, once validated for each PR on BitBucket.
(follow the same above steps to filter on Hivel for time related metrics)
On Bitbucket:
For each PR by the developer:
Identify the timestamp of the first commit included in the PR.
Identify the timestamp when the PR was merged.
Calculate the difference (merge time - first commit time).
Calculate the average of these differences across all PRs in the period.
2. Validate Coding Time
On Bitbucket:
For each PR:
Find the time of the first commit in the PR.
Find the time when the PR was opened.
Calculate the difference (PR opened time - first commit time).
Calculate the average coding time.
3. Validate Review Time
On Bitbucket:
For each PR:
Note the time when the PR was opened.
Find the time of the first review comment or approval.
Calculate the difference (first review time - PR opened time).
Average this across all PRs.
4. Validate PRs > 400 Lines of Code
On Hivel:
Go to Pull Request screen and filter out the team, developer, time frame, and PRs > 400 LoC - for the list of large merged PRs in that duration.
On Bitbucket:
Filter all PRs merged by the developer in that time period.
For each PR, check the number of lines changed.
BitBucket recommends running this command line to fetch the PR size
"git fetch origin pull/PR_ID/head:pr-branch git diff --stat main...pr-branch"
Replace
PR_IDandmainwith the appropriate PR number and base branch.
Count how many PRs exceed 400 lines changed.
5. Validate PRs Merged Without Review
On Hivel:
Go to Pull Request screen and filter out the team, developer, time frame, and click on Unreviewed PRs - for the list of PRs merged without review in that duration.
On Bitbucket:
Filter out a small time period.
List Merged PRs:
Go to the repository's Pull Requests page.
Set the filter to show only "Merged" PRs.
Check Approval Status:
Open each merged PR.
In the PR details, look for the "Reviewers" section. If there are no approvals listed, the PR was merged without approval.
6. Validate MTTR (Mean Time to Repair)
On Hivel:
Go to Pull Request screen and filter out the team, developer, time frame, and click on MTTR tile - for the list of CFR PRs and their respective MTTR.
On Bitbucket:
Identify PRs labeled with “hotfix” or similar (e.g., title contains "hotfix", "bugfix", "urgent").
Calculate cycle time for each hotfix PR (first commit to merge).
Average these times.
7. Validate Deployment Frequency
On Hivel:
Go to Pull Request screen and filter out the team, developer, time frame, and click on Deployment Frequency tile.
On Bitbucket:
Go to the repository's Pull Requests page.
Filter by:
State: Merged
Author: The developer's username
Destination branch: master or main
The UI does not support filtering by date, so you must manually count PRs merged in your time window by checking their merge dates
Count the total number of PRs merged into the master or main branch during the selected time period.
Calculate deployment frequency as:
8. Validate Active Days
On Hivel:
Go to Dev360 screen and filter out on the time period and developer to get a summary of GIT activity done by the developer.
On Bitbucket:
Identify all days where the developer had any activity:
Commit, PR created, PR reviewed, or comment posted.
Repository Commits and PRs: You can manually filter commits and pull requests by author in the repository view, then check the dates to see which actions occurred during the week.
Local Git Logs: By cloning the repository and using
git logorgit shortlogfiltered by author and date, you can see a developer’s commit activity for the week.
9. Validate Flashy Reviews
On Bitbucket:
For each PR, calculate review time (first review - PR opened).
Identify PRs with review time less than 5 minutes.
Count these PRs.
Last updated
Was this helpful?