When does a task's Cycle Time begin and end?
This tests your practical grasp of process metrics. Define Cycle Time as starting when active work begins ('In Progress') and ending when 'Done' (shippable). Contrast it with Lead Time (request to delivery). A red flag is confusing the two or being too vague.
What's really being asked
This question tests your ability to translate a theoretical agile metric into a concrete engineering workflow. The interviewer wants to see if you think about process efficiency, not just code. They are evaluating your precision with definitions and your ability to explain the 'why' behind a metric, which signals a senior, process-oriented mindset. Can you distinguish between a team-facing metric (Cycle Time) and a customer-facing one (Lead Time)?
The full answer
First, a precise start point: Cycle Time begins the moment a team member starts active work on an item. This is typically when a ticket is moved from a 'Ready for Dev' or 'To Do' column to an 'In Progress' or 'Development' column on a Kanban board. It's the start of value-adding activity.
Second, a precise end point: It ends when the work on that item is completed from the team's perspective. This is often when code is merged to the main branch and passes all CI checks, or when the ticket moves to a 'Done' or 'Ready for Release' column. The key is that it's potentially shippable.
Third, the reasoning: Explain that these specific start and end points are chosen to isolate and measure the team's internal development efficiency. It filters out external delays like time spent in the backlog or waiting for a scheduled release, making it an actionable metric for the engineering team itself.
Fourth, the contrast with Lead Time: Proactively differentiate it from Lead Time, which starts when a request is made by a stakeholder and ends when it's delivered to the customer. This demonstrates a complete understanding of the value stream.
The mistakes people make
Confusing Cycle Time with Lead Time is the most common and significant red flag. Answering that it starts 'when the ticket is created' is incorrect; that's the start of Lead Time.
Another weak answer is being too vague, for example, 'it's the time it takes to do the work'. This lacks the specific workflow stages requested and shows a superficial understanding. A senior candidate must connect the concept to concrete states like board columns.
Failing to explain the 'why' is a missed opportunity. Simply stating the definition is a junior-level answer. Explaining its purpose for measuring team efficiency is a senior-level answer.
What usually comes next
Expect questions like, 'If your Lead Time is high but Cycle Time is low, what does that indicate?' (Answer: Bottlenecks outside of active development, like slow prioritization or long code review queues). Or, 'How would you use this metric to improve your team's process?' (Answer: To identify bottlenecks, justify Work-In-Progress limits, or improve story breakdown).
A concrete example
On my last team, our average Cycle Time from 'In Progress' to 'Merged' was 4 days, which was consistent. However, our Lead Time was over 30 days. By analyzing the data, we found that tickets spent an average of 15 days in the 'Code Review' queue. This wasn't a development speed issue, but a review bottleneck. We used this data to implement a policy that no new work could be started if there were more than 5 PRs awaiting review, which dramatically reduced our overall Lead Time.
Interview question
Which pair of workflow stages best defines the start and end points for measuring a task's Cycle Time?
- a.From when the task is assigned to a developer to when it passes all quality assurance tests.
- b.From when the task is moved to 'Ready for Dev' to when its code is merged to the main branch.
- c.From when the task is created in the backlog to when it is released to end-users.
- d.From when a team member begins active work ('In Progress') to when the task is completed and potentially shippable ('Done').Correct
Why? this is the answer
Cycle Time specifically measures the team's internal efficiency, starting when active work begins (e.g., 'In Progress') and ending when the work is completed and potentially shippable ('Done'). Option C describes Lead Time, which encompasses the entire value stream from request to customer 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