How Faros computes Lead Time

What is Lead Time?

The lead time metric is loosely defined as the time it takes to deliver software changes. There is some latitude in the granularity of the changes that are considered for the computation, as well as the start and end times to consider. For instance, the DORA metrics as defined by the DevOps Research and Assessment Organization, only consider the time from when a commit gets checked in till the time that it becomes available in production.

The default lead time calculation in Faros operates on pull requests (PRs) as the unit of change, and measures the time from when a PR is created to the time when the change associated with that particular PR gets released to production. Averages, medians, or other percentiles can then be computed to understand lead time across PRs in the organization.

Lead time of a change = Timestamp(Change deployed to Prod) - Timestamp(PR for change created)

The default calculation can be customized to consider other starting points, such as the time when the task associated with the PR was first added to the backlog. But we have found that the PR creation time serves as a better default starting point since different teams in an organization often differ on their diligence/hygiene when it comes to attaching PRs to tasks.

How does Faros compute Lead Time?

Faros builds a complete trace of every PR from creation to release in production. At a minimum this requires data from your source control and CI/CD systems.

Typically the data we gather through CI/CD integrations (whether through instrumented events or through periodically scheduled connectors) contains the following information:

CD information: Which artifact got deployed for which application, in which environment, at what time?

CI information: Which commit got built into which artifact, and how long did the build take?

Given these two types of information, Faros goes a step further and imputes changesets, i.e., all the changes/commits that got deployed in a specific environment since the last deployment in that environment.

Now given all this information, Faros can infer the first time a change got deployed to a specific environment, and the lead time flow is then defined as:

Faros computes both the overall time span as the end-to-end lead time, as well as every intermediate time span. If a specific stage is missing, e.g., a change was deployed to Prod directly from Dev without going through Staging, then Faros automatically computes the Time in Dev as the time from the deployment to Dev, to the deployment to Prod, and assumes a Time in Staging of 0.

If your development process differs from the standard process, we do support creating custom flows. You can review this document to learn more about custom flows.