Change lead time

The starting event matters

A ticket can wait in a backlog for weeks before someone commits code. That waiting period may matter to the business, but it falls outside change lead time when the measure starts at the commit.

Similarly, a pull request can contain several commits. A reporting system needs an explicit rule for associating those commits with the production deployment. Squash merges, cherry-picks, and release branches can make that association more complicated than matching one identifier.

Follow a change through the pipeline

For an illustrative service, a change is committed Monday afternoon, merged Tuesday morning, and deployed Wednesday afternoon. Its elapsed lead time spans implementation after the first commit, review, integration, and any release waiting.

If the team shortens review by two hours but retains a weekly deployment window, the overall improvement may be modest. The longest delay can sit outside the stage receiving the most attention.

Compare compatible measurements

Do not substitute a ticket's lead time or an opened-to-merged pull request duration without changing the label. Those measures answer related questions with different boundaries.

Inspect the distribution as well as a summary statistic. A few long-lived changes can distort an average, while unfinished changes are absent from a completed-deployment report. Investigate representative slow items and confirm that the event mapping is correct before making a process change.