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 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.
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.
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.
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.
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.
