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 components of the lead time 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 declaring deployments docid\ pyfvkh5axzsvjnjmlbzfl