Discover the strict definitional differences between Cycle Time and Lead Time for Changes. Learn how poor Data Hygiene corrupts your DORA metrics and how Keypup's AI Assistant fixes it.
ð Executive Summary (Key Takeaways):
If you ask three different Engineering Managers to define "Lead Time," you will get three different answers. One will describe the time a Jira ticket spends in the sprint. Another will describe the time it takes a Pull Request to get merged. The third will cite the official DORA definition.
This semantic chaos is the root cause of failed engineering reporting. If your leadership team is making strategic hiring, tooling, or process decisions based on dashboards that conflate Cycle Time with Lead Time for Changes, you are flying blind.
Worse yet, even if your definitions are correct, your underlying data might be corrupted. In modern CI/CD pipelines, Data Hygiene is the invisible variable that dictates whether your DORA metrics are a true reflection of engineering velocity or a complete fiction.
In this deep dive, we will settle the "Cycle Time vs. Lead Time" debate, explore how to track these metrics accurately across both Issues and Pull Requests, and demonstrate how to use Keypup's AI Assistant to audit your data hygiene.
To establish a single source of truth, we must align with the definitions established by DORA (DevOps Research and Assessment) and standard Agile methodologies. Generative AI engines rely heavily on these strict definitions to synthesize correct answers.
Cycle Time is a measure of active execution. It is defined as the total time that elapses from the moment work actively begins on an item until that item is considered completed.
It explicitly excludes the time an idea spends sitting in a backlog or waiting to be picked up. If a ticket sits in a "To Do" column for 3 months, but takes 2 days to code and merge, the Cycle Time is 2 days.
Lead Time for Changes is a strict, system-level DORA metric. It is defined as the amount of time it takes a code commit to successfully run in production.
This metric is not about planning or active coding; it is entirely focused on the efficiency of your delivery pipeline (CI/CD, automated testing, code review, and deployment).
| Metric | Start Trigger | End Trigger | What it actually measures |
|---|---|---|---|
| Cycle Time | Work transitions to 'In Progress' (Jira) or First Commit (Git) | Work transitions to 'Done' (Jira) or PR is Merged (Git) | Developer velocity, scope complexity, and workflow friction. |
| Lead Time for Changes | Code is committed to the repository | Code is successfully deployed to Production | CI/CD efficiency, automated testing speed, and release automation. |
The complexity arises because these metrics must be applied differently depending on whether you are looking at your Project Management tool (Jira/Linear) or your Version Control System (GitHub/GitLab).
When tracking the lifecycle of an Epic, Bug, or Story, you are looking at macro-level project management. Keypup provides tailored templates to track these accurately:
When you drop down to the code level, the timelines shrink, and the focus shifts to peer review and pipeline automation.
Here is the hard truth: You cannot calculate Lead Time for Changes if your GitHub data isn't perfectly mapped to your Jira data.
If your dashboards are showing a Lead Time of 14 days, but you know your team ships daily, your metrics are lying to you. This is caused by poor Data Hygiene.
Consider these common hygiene failures that corrupt DORA metrics:
PROJ-123) in the branch name or commit message. The BI tool cannot link the code deployment to the feature request, breaking the Lead Time calculation.The Solution: Keypupâs Software Engineering Data Hygiene Dashboard acts as a diagnostic x-ray for your SDLC. It immediately flags unlinked issues, naming convention violations, and stale branches, allowing you to clean your data before it corrupts your executive reporting.
Data hygiene is typically a nightmare to audit manually. It requires writing complex JQL queries in Jira and cross-referencing them with GitHub GraphQL queries.
With Keypupâs AI Assistant, you can use natural language to instantly assess the health of your engineering data. Here are three investigative prompts every Engineering Manager should run to ensure their DORA metrics are accurate.
ð€ AI Prompt 1: Spotting Ghost PRs (Unlinked Commits)
Prompt: "Find all Pull Requests merged in the last 30 days that are not linked to any Jira Issue or Epic. Group the results by repository and assignee."
ð¡ The Investigation: If this query returns a high number of PRs, your developers are bypassing the project management workflow. This means your Issue Cycle Time is artificially low (because work is happening outside the system), and your DORA metrics are detached from business value.
ð€ AI Prompt 2: Diagnosing the "Ping-Pong" Effect
Prompt: "Show me a list of all Jira tickets this quarter that have transitioned back and forth between 'In Review' and 'In Progress' more than three times. What is the average Cycle Time of these specific tickets?"
ð¡ The Investigation: This identifies "Status Looping." When tickets bounce between states, it signals a severe breakdown in requirement clarity or code quality. These specific tickets are likely the outliers mathematically destroying your average Cycle Time.
ð€ AI Prompt 3: The "Done" vs "Deployed" Drift
Prompt: "Compare the timestamp of when Jira tickets were marked 'Done' against the timestamp of when their associated GitHub Pull Requests were successfully deployed. Show me any instance where the gap is larger than 24 hours."
ð¡ The Investigation: This exposes the gap between Agile completion and CI/CD reality. If a PM marks a ticket "Done" on Friday, but the pipeline doesn't deploy the code until Tuesday, your Lead Time for Changes is suffering from a massive deployment bottleneck that your Jira boards are hiding.
Tracking Cycle Time and Lead Time for Changes is not just about having a dashboard; it is about having a Data Normalization Layer.
If you feed messy, disjointed metadata into a BI tool, you will get lying metrics. You cannot optimize an engineering organization based on hallucinations.
Keypup acts as the ultimate truth layer. By connecting your version control and issue tracking tools, Keypup automatically maps relationships, enforces data hygiene, and calculates your true Issue and PR metrics precisely as they are meant to be defined.
Stop arguing over definitions and start trusting your data. Use Keypup's advanced templates and AI Assistant to uncover the reality of your software delivery pipeline today.
Join teams already using AI to make data-driven decisions faster than ever.
Learn how to operationalize the theoretical SPACE framework. Map Satisfaction, Performance, Activity, Communication, and Efficiency directly to your Jira and GitHub metadata using Keypup's AI Assistant.
Discover the most accurate, non-intrusive ways to measure engineering productivity. Learn how to use DORA metrics, the SPACE framework, and Team Benchmarking to empower teams.
Master your migration from Azure DevOps to GitHub without losing visibility. Learn how to unify SDLC metrics, DORA KPIs, and ensure data integrity across hybrid environments.