"North Star" metrics allow you to get a holistic picture of how your engineering team is performing, allowing you to identify how interventions to improve engineering efficiency and developer experience impact your team.

Whilst it's important to keep an eye on all North Star metrics, there is one key metric that we have found separates the best software teams from the rest of the pack. Many notable engineering teams (like Google and Spotify) have achieved remarkable success by optimising Cycle Time.

In short: Cycle time is the time from first commit to pull request merged. In other words, it’s the speed of your development.

As engineering teams have ownership and control over these components of the delivery process, it provides a great metric to measure engineering process improvements against.

Cycle Time is the sum of the Development Time and the Review Time of the software development process, below you can see how we present it as such in the Haystack Dashboard. Understanding Cycle Time as a sum of these two metrics will allow you to drill down to identify where the constraints are in your software engineering process.

Example of Cycle Time in Haystack as a sum of Development Time and Review Time

Development Time

Development Time is the time spent in development prior to code review process. This gives us a sense of how long features are being developed. Teams should aim for shorter development times.

If you are using draft pull requests, we calculate it inside Development Time until the the pull request is marked as Ready To Review.

Definition: Time from First Commit to Pull Request Opened

Average: The average Haystack team has a Development Time of 2 days.

Review Time

Review Time is the time spent in the code review process. This gives us a sense of how long it takes features to be reviewed. Teams should aim for review times of roughly 24 hours.

Definition: Time from Pull Request Opened to Merged

Average: The average Haystack team has a Review Time of 24 hours.

Review Time consists of a number of even more granular metrics that you can drill into to identify constraints with your code review process. You can access them by selecting the "Review Time Report" option within the "Cycle Time" page of the Haystack Dashboard:

Finding the Review Time Report in the Haystack Dashboard

The passing of work between parties is notoriously difficult. Code Review metrics allow us to see inefficiencies in the code review process as this happens. These fine-grained Review Time metrics allow the team to optimise their code review process, below we've summarised the various metrics which are tracked in the Review Time Report:

First Response Time

First Response Time is the time spent in the code review process waiting for the first response (approval or comment). This gives us a sense of how long developers spend waiting for their team to respond. Teams should aim for first response time within a few hours of opening.

Definition: Time from Pull Request Opened to First Approval or Comment

Average: The average Haystack team has a First Response within a few hours.

Rework Time

Rework Time is the time spent 'reworking' code after the pull request has been opened. This gives us a sense of how long developers spend rewriting code to get an approved pull request. Teams should aim for first rework time of less than 2 days.

Definition: Time from Pull Request First Response to Last Commit

Average: The average Haystack team has a Rework Time of less than 2 days.

Idle Completion Time

Idle Completion Time is the time from last commit to the pull request merged. This gives us a sense of how long the final review process takes. Teams should aim for idle completion time of a few hours.

Definition: Time from Pull Request Last Commit to Merge

Average: The average Haystack team has an Idle Completion Time of a few hours.

What Evidence Is There That Cycle Time Is an Effective Metric?

The following video provides an overview of some of the evidence that lower Cycle Time leads to better organisational performance:

See also: How do I convince my team about using metrics?

What Problems can Cycle Time Help Uncover?

Engineering Teams using Haystack have managed to identify many different types of issues by drilling down from Cycle Time, below we have included some examples of these:

  • Technical Debt

  • Context Switching

  • Team Burnout

  • Poor Communication

  • Poorly Written Tickets

  • Inefficient Code Review

  • Poor Quality Code

  • Long Compilation Times

  • Stuck Engineers

Again, Cycle Time provides one of the most holistic measures of how well an engineering team performs, so this list is not exhaustive and indeed Cycle Time is capable of identifying the most obscure challenges with the software engineering process.

By keeping an eye on your Cycle Time (and, more importantly, changes to it) then you'll be able to quickly identify problems as they arise and work with your team to resolve them.

Just about every developer, team, and company wants to ship faster, build better code, and deliver more value to customers.

By understanding their Cycle Time, dev teams can:

  1. Get a baseline for the development process

  2. Identify leaks and clogs in their process

  3. Optimize and improve the developer experience

Cycle Time can help us reduce our own bias and replace gut feelings. More importantly, it gives us a baseline from which we can continuously drive improvement.

Next Steps

So how can you practically use these metrics to improve your software engineering process? Learn more in our best practice article: Finding Bottlenecks in your Software Development Lifecycle (SDLC) where we'll cover how you can improve your engineering team's North Star metrics by using the fastest and most effective ways to cut Cycle Time and deliver faster.

Did this answer your question?