Team Velocity

The Team > Velocity dashboard represents a set of key metrics that summarise the total cycle time of the entire software engineering lifecycle for the selected team. Cycle time is one of the most widely tracked metrics across engineering teams and is a great way to identify bottlenecks in the development process. Since cycle time begins with the first commit and ends with Production deployment, it gives a complete and holistic view of all the steps in the process; enabling you to understand what's working, and what's not.

Cycle Time dashboard

Video walkthrough

Data source

Git/VCS apps
CI-CD tools

Filters

Date range picker
Custom team picker
Individual picker
Repository: to drill down into specific Git repositories
Merged PRs only: to exclude any PRs that are not merged
Base branch: to filter PRs that are cut from/merged to a specific branch

💡

The default branch names in GitHub & GitLab <v14.0 is main and master in case of Bitbucket & Gitlab v14.0

Cycle time breakdown

The overall software development lifecycle can be broken down into multiple stages adding up to what we call Total Cycle Time. The stages are:

Coding time: Avg. time spent from the first commit until the PR is created.
Pickup time: Avg. time elapsed from the PR being raised for review till the review process actually starts. The earliest recordable review action is a comment/approval/request changes.
Review time: Avg. time elapsed by PRs in the review process after the first recordable review action. This includes all time spent iterating on the PR, making changes until they get merged.
Deploy time: Avg. time elapsed from PR merge until deployment to production environment. The deployment data is sourced from deployment systems integrated with Hatica. Refer to the how to configure DORA dashboard document for more information.

This widget also provides a comparative trend vs. the last period, so if the data range is set to 30 days, say 1-Jun to 30-June, the comparison is versus the previous 30 days which is 2-May to 31-May.

Cycle time trend

The Cycle time trend provides a day-wise view of cycle time along with a list of PRs that contributed to the cycle time. Click on a day to bring up the context menu to see a full list of PRs along with the cycle time for each PR.

The light blue trend line is a linear regression plot of how the cycle time is trending within the specified date range. A downward trending plot is better because it indicates reducing cycle times through this period.

Use the cluster plot to view cycle time for every PR that meets the selected filter conditions.

Cycle time distribution

The Cycle time distribution is a histogram plot of the distribution of Cycle time across a few pre-defined categories. This helps visually identify

Outliers that might be substantially increasing the cycle time
A 'fat-middle' syndrome where bulk of the PRs are taking 2-4 days
PRs that have very low cycle time (<1hr, <8hrs etc)

As a distribution plot, this helps teams focus on PRs & PR trends that drive a shift-left on the entire distribution.

Ways to reduce your cycle time

Starting small and fast: You can deliver more by starting with smaller PRs and producing customer deliverables quickly.
Automate, automate, automate: Use automated tools to save efforts and delivery time. You can implement continuous integration through automated releases and invest the remaining time in coding.
Slicing the giant PR: Breaking the work items into smaller chunks and iterating frequently enables your team to perform better. It also reduces the pickup time and review time for the pull requests significantly. The general industry standard for PR size is 300 lines of codes(LOC).

Use cases

Understand end-to-end cycle time for the entire engineering org
Benchmark teams vs the org-wise baseline
Identify life cycle stages which are leading to higher cycle times at the org or team level
Identify teams, repos that are not syncing the Deployment data

Insights

Use this dashboard to get insights irto the following

How much time is spent in coding?
How much time do PRs spend waiting for reviews?
How quick are the reviews?
How quickly do we deploy merged PRs into production?
What is the relative change in cycle time for each of the development stages compared with the previous period?

FAQs

We use GitFlow-branching, how do we compute cycle times for a specific release?

Use the Head branch to filter for all PRs merged to the development branch. As the branch name might vary across Repos it is important to provide the correct branch name in this filter

We use trunk-based development, how do we compute cycle times for a specific trunk?

Since the trunks are short-lived and merge to the master branch; the Base branch filter can be set to master to filter all PRs merged to the master branch

If the data is not filtered by Base or Head branch, what is the cycle time representing?

In this case, the Cycle time is computed for all PRs across all branches in Git, regardless of what is the base branch or the head branch.

My team relies on Local branches for development & does not merge these into Remote branches. How is the cycle time computed?

Cycle time is only computed for Remote Git branches; local branches are not included in computing cycle time.

How to compute Cycle time only for PRs that are merged and ignore PRs that are in other states?

Use the “Merged PRs only” filter to exclude PRs in other states

In some scenarios I am observing the different cycle time components don't add up to total cycle time, how to interpret this?

Each stage of the cycle time is averaged individually, and unless the "Merged PRs only" filter is enabled, Hatica will look at all open, merged and deployed PRs and average their total cycle time and it's components, i.e. coding, pickup, review and deploy individually. Following this, you can see that coding time will be averaged for all PRs that are open, merged and deployed. Pickup time will be averaged for all PRs that are still in-review, merged or deployed. Review time will be averaged for all prs that have been picked up for review, merged, or deployed. Deploy time will be averaged for all deployed PRs.

How is cycle time computed for PRs that have not been deployed?

Cycle time for undeployed PRs is the elapsed time until the last update for example:

if the PR has been merged then cycle time is the cumulative time from first Commit until merge.
if the PR is currently in the review phase then cycle time is the cumulative time from first Commit until now & will keep increasing until the current phase is completed.

How are draft PRs handled?

Currently draft PR analytics can only be pulled using the Activity > Code dashboard. Support for draft PRs across Hatica is coming soon.

How is rebasing/squashing handled?

Currently rebasing and squashing aren't accounted for; support for these is coming soon.