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.
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 |
Preparation¹ | The median delay between an issue being marked "in-progress" and a first commit being authored in a linked pull request. |
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. |
¹ This segment is available on-demand, and is currently supported with JIRA and Linear.
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.
