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 139,623 false true unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type 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