11min

Vitals

Echoes continuously evaluates the software delivery performance of your organization, giving you confidence that sustainable progress is being made in the right direction. It relies on industry-standard made popular by the DORA's State of DevOps research program and the associate book Accelerate. This research has led to the development of four measures of delivery performance: two measures of tempo, and two measures of stability.

These measures can be found in Echoes at https://app.echoeshq.com/metrics/vitals. Easily understand if your software delivery performance is steady, improving, or slowing down by exploring your metrics evolution over time.

Lead time

Lead time is the time it takes to go from a customer making a request to the request being satisfied. However, in the context of product development, where we aim to satisfy multiple customers in ways they may not anticipate, there are two parts to lead time: the time it takes to design and validate a product or feature, and the time to deliver the feature to customers. — Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.

Echoes computes the delivery part of the lead time: the time it takes for work to be implemented, reviewed, tested, and delivered. The lead time tab shows what is the typical journey of the change request from the initial commit implementing the change to the change being deployed.

Lead time display

Lead time display
Lead time display

The "Lead time" tab shows:

  • In the tab itself, the median on the selected period and the median on the previous period with the variation in percent.
  • A breakdown of the lead time across the segments described below.
  • The evolution of lead time over time.
  • The breakdowns of datapoints across teams and aggregated upward.

Components of the lead time

The lead time is broken down into 4 segments. We use GitHub wording for brevety, but all descriptions below apply equally to GitLab merge requests.

Phase

Description

Development

The median delay between the first commit and a pull request being opened or marked as ready for review when it was opened as draft.

Review

The median delay between a pull request being ready for review and its first approval.

Merge

The median delay between a pull request being approved and merged.

Deployment

The median delay between a pull request being merged and deployed to production.

Declaring deployments

Contrary to the first three segments (Development, Review, Merge) which are automatically computed based on activity, computing the Deployment delay requires for deployments to be declared through the Releases API. There are many different ways to push code to production: this API gives you control on what you consider to be a deployment event.

Deployment frequency

We settled on deployment frequency as a proxy for batch size since it is easy to measure and typically has low variability. By “deployment” we mean a software deployment to production or to an app store. A release (the changes that get deployed) will typically consist of multiple version control commits, unless the organization has achieved a single-piece flow where each commit can be released to production (a practice known as continuous deployment). — Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.

Echoes computes the deployment frequency using both the tagging events as detected on GitHub or GitLab, and the deployment events as notified through the Releases API.

Deployment frequency display
Deployment frequency display

The "Deployment frequency" tab shows:

  • In the tab itself, the average on the selected period and the average on the previous period with the variation in percent. The average is computed on the git tag events and the deployment events (confer Releases) combined.
  • The breakdown of datapoints across teams.



Updated 04 May 2022
Did this page help you?
Yes
No