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 is broken down into 5 segments. We use GitHub wording for brevity, 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 ready for review (the exact measurement will depend on whether draft-modes and whether review-requests are used). |
Review | The median delay between a pull request being ready for review and when it is approved (the exact measurement will depend on whether draft-modes, are used or multiple-reviews are made). |
Merge | The median delay between a pull request being approved and merged (the exact measurement will depend on whether multiple-reviews are made). |
Deployment | The median delay between a pull request being merged and deployed to production. |
Note that when a segment for a pull request contains week-ends, we discount the week-end duration from the lead-time.
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.