How long does it take to get a new feature to a customer?
Lead Time measures the product team's time to deliver value to users.
Lead Time is not to be confused with Cycle Time which measures only the time from the moment when a team picked up the PBI in a Sprint Planning meeting and the time when the team proclaims the PBI done, meaning that it is useable and meets the Definition of Done.
It is not always easy to decide when to start the clock for counting the lead time - when the customer requested a feature, when the work item is created or perhaps when the Product Owner approves it. Choose one and stick to it to get consistent and meaningful data from this metric.
It is not trivial to get the data as you have to have Continuous Delivery in place to get the data automatically. It is worth trying to measure Lead Time (and continue to do so) to remove the impediments resulting in better technology and business culture.
Lead Time was identified as one of the most important predictors of software delivery performance [Kim, Humble, and Forsgren, 2018]. That is why you should constantly monitor it and its trends. If Lead Time indicates opportunities to improve, analyze other more specific metrics to decide how to proceed (e.g. Backlog health, Build and Integration Frequency, Release Frequency and Mean Time To Repair). Introduce improvements one by one, starting from the one with the most significant gain.
Want to improve the techniques and processes to deliver validated requirements to customers faster? Lead Time can expose difficulties such as the ability to refine the requirements into well-defined Product Backlog Items, a faulty development process, team burning-out handling maintenance work, Product Backlog filling up with requirements, and others.