How we measure lead time
The definitions every pilot contract uses, published so your team can check them before the call.
| Term | Definition |
|---|---|
| Lead time | From the first move into an in-progress status to the deploy that reaches production. Median and 85th percentile per ticket, and median per epic. |
| Statuses counted | Listed by name in the contract appendix for your Jira workflow, before the baseline is pulled. Changing the workflow mid-pilot doesn't change the list. |
| Throughput | Tickets and epics finished per week. We report throughput next to lead time, so smaller tickets can't pass for faster delivery. |
| Deployment frequency | Production deploys per week, from your CI or release tags. |
| Change failure rate | Share of deploys followed by a rollback, hotfix or incident within 7 days. |
| Window | Baseline: the 90 days before we start. Result: the last 4 weeks of the pilot. |
| Who runs it | The query is run in your Jira by one of your engineers, before and after. We read the result with you. |
| Before figures | The baseline figures are signed off by your team leads before work starts. |
| Messy data | Where tickets aren't tagged well, we use Git and pull-request dates and mark those numbers as estimates. |
| Payment | The pilot's second half is due once the changes have run for two weeks with your people (the tests, release rhythm and automations named in the contract). Lead time before and after goes in the report either way; it is not what we are paid on. |
Ask about the method.
If your Jira workflow doesn't fit these definitions, say so. We'll tell you what we'd count instead, before any contract is written.
Write to usThen a 30-minute call in your office hours.