When Does Cycle Time Begin and End?
This tests your grasp of process metrics. Define Cycle Time as starting when active work begins ('In Progress') and ending when it's 'done' (code complete/merged), not when the ticket was created. A red flag is confusing this with customer-facing Lead Time.
What's really being asked
This question tests your ability to define and use process metrics for team improvement. The interviewer isn't looking for a dictionary definition. They want to know if you can articulate a clear, measurable boundary for team efficiency that is distinct from external factors like backlog prioritization. It shows you think about process optimization from an engineering control perspective.
The full answer
First, a precise start point: Cycle Time begins the moment a team member pulls a task from a 'Ready' or 'To Do' state into an active work state like 'In Progress'. This is the moment the team commits to working on it.
Second, a precise end point: The end point is when the work is considered 'done' from the engineering team's perspective. This could be when the code is merged to the main branch or when it's in a 'Ready for Release' state. A senior answer acknowledges this ambiguity and explains the importance of the team agreeing on a consistent definition.
Third, the reasoning: Explain that this definition isolates the development process. It measures the time to execute, making it a powerful tool for identifying internal bottlenecks like slow code reviews, flaky tests, or environment issues. It answers the question, 'How long does it take us to build something once we start?'
Fourth, the contrast: Briefly differentiate it from Lead Time, which starts from the customer request and ends at delivery. This shows you understand the full value stream and why isolating Cycle Time is valuable for the engineering team.
The mistakes people make
Confusing it with Lead Time is the biggest red flag. Saying Cycle Time starts 'when the ticket is created' or 'when the PM prioritizes it' is incorrect. That includes backlog wait time, which is part of Lead Time.
Another common mistake is giving a vague definition like 'when we start working on it' without specifying the exact workflow column or event. Metrics require precision. An answer without a specific trigger (e.g., moving the ticket to the 'In Progress' column) is a sign of shallow understanding.
What usually comes next
'How would you use Cycle Time data to improve your team's process?' (Look for outliers, identify bottleneck stages). 'If your average Cycle Time for a feature is 5 days, is that good or bad?' (The answer is it depends on team context and predictability is more important than the raw number). 'What are the first things you'd investigate if Cycle Time starts increasing?' (Code review queues, test failures, requirement ambiguity).
A concrete example
A ticket sits in the 'Ready for Dev' column for 3 weeks. This is part of Lead Time. An engineer then pulls it into 'In Progress'. The Cycle Time clock starts. The work takes 2 days in development and 1.5 days in code review. Once the PR is merged and the ticket moves to 'Ready for Deploy', the clock stops. The Cycle Time is 3.5 days. This number is actionable for the team, whereas the 3 weeks of wait time is an issue for product and prioritization processes.
Interview question
To accurately measure its internal development process efficiency, how should a team define the start and end of Cycle Time for a task?
- a.From when the ticket is prioritized until the task moves to 'In Progress'.
- b.From when the task moves to 'In Progress' until the code is merged.Correct
- c.From ticket creation until the feature is released to customers.
- d.From when the task moves to 'In Progress' until the feature is released to customers.
Why? this is the answer
Cycle Time correctly measures the active development phase, providing an actionable metric for the engineering team. A common error is confusing it with Lead Time (Option C), which measures the entire duration from customer request to delivery.
Just read this? Test yourself on what you have been reading.
Read the original → agile-academy.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles