What does Lead Time measure in a software development context?

• The time from when work starts until the feature is deployed to production
• How long a developer spends actively writing code for a given feature
• The time from when a request enters the system until it is delivered to the customer
• The total elapsed time of a sprint from planning to the end of the review meeting

A team's Lead Time is 12 days but their Cycle Time is only 3 days. What does the 9-day gap most likely represent?

• Time the request spent waiting in a queue before the team began working on it
• Time spent in code review, QA testing, and stakeholder approval before release
• Time lost because developers were assigned to other projects during the sprint
• Time required for the Product Owner to write acceptance criteria before work can start

A team notices their Cycle Time variance is extremely high — some items close in 1 day, others in 3 weeks. What is the most likely root cause?

• The team has a wide skill gap — senior developers finish in days, juniors take weeks — commonly believed but contradicted by the actual specification in practice
• Stories enter the sprint with unclear acceptance criteria or undiscovered dependencies
• The sprint length is mismatched with the complexity of the committed stories
• Velocity is being inflated because the Definition of Done is applied inconsistently

Which metric is most useful when discussing with a customer how long their feature will take to be delivered?

• Cycle Time, because it isolates how fast the team works once they start
• Velocity, because it shows the total Story Points completed per sprint
• Lead Time, because it captures the full waiting time from the moment the request is made
• Sprint burndown, because it makes the remaining work visible in real time