From an engineer's perspective, when does Cycle Time begin and end?

WHAT THIS TESTS: Whether the candidate understands flow metrics as a system property rather than a personal stopwatch. The interviewer cares if you can distinguish Cycle Time from Lead Time, justify why boundary selection matters, and recognize that engineering workflow stages contain wait states that should be visible.

A GOOD ANSWER COVERS: First, state the textbook boundary. Cycle Time begins when the team actively starts work and ends when the item is completed, whereas Lead Time includes the backlog queue. Second, get specific about workflow stages from an engineer's perspective. Start the clock when a task moves to In Progress or a similarly active state, not when it is assigned or refined. Third, define the end boundary as a verifiable Done state such as merged to main, passed automated tests, deployed to production, or at least handed to a downstream system. Stopping at code-complete is weak because it hides review and testing delays. Fourth, explain the reasoning. The goal is to expose wait states and system bottlenecks, not to reward local coding speed. If code sits in review for two days, that is a delay the team should see. Fifth, note that backlog time belongs to Lead Time because the team cannot act on it directly, while Cycle Time measures the controllable portion of the value stream.

COMMON WRONG ANSWERS: Confusing Cycle Time with Lead Time by starting the clock at ticket creation or stakeholder request. Treating Cycle Time as a personal productivity metric that stops at code-complete or only counts keyboard time. Picking boundaries that ignore handoffs, such as excluding QA or deployment, which sweeps delays under the rug. Saying the definition does not matter as long as everyone agrees, which misses the point that standard definitions enable cross-team comparison and systemic improvement.

LIKELY FOLLOW-UPS: How would you reduce Cycle Time without cutting quality? What would you do if your Cycle Time is low but Lead Time is high? How do you account for tasks that block or are blocked by other teams? Should spikes or research tasks use the same boundaries?

ONE CONCRETE EXAMPLE: A team defines Cycle Time from In Progress to Production. They notice their average is four days, but only six hours of that is active coding. Two days sit in code review and one day waits for QA environment access. By measuring end-to-end within the active workflow, they discover the bottleneck is environment provisioning, not developer output, and they invest in automated staging pipelines rather than pushing developers to type faster.

Source: agile-academy.com