Flow Metrics

## Two clocks over one item A work item lives longer than the stretch the team spends on it. Someone asks for it, it is accepted, it waits in a queue, eventually the team starts it, it moves across the board — sometimes blocked, sometimes waiting on someone else — and finally it is delivered. Flow metrics run two different clocks over that life, and the only thing separating them is where each clock starts. **Lead time** starts when the request is accepted into the system and stops when the item is delivered. It answers the requester's question: how long from asking to having? **Cycle time** starts when the team actually begins work on the item and stops at the same delivery point. It answers the team's question: once we pick something up, how long until it is out? Both are elapsed calendar time, not effort. A day an item spent blocked is a day on both clocks, and that is deliberate — delay is what a requester experiences, and subtracting the waiting quietly turns a delay measure into an effort estimate. ## The difference between them is queue | | Lead time | Cycle time | |---|---|---| | Clock starts | request accepted into the system | team starts work on the item | | Clock stops | item delivered | item delivered | | Includes waiting before work starts | yes | no | | Question it answers | how long does a requester wait? | how quickly does the team turn work around? | | Moves when | the queue grows or is reordered | the work itself speeds up or slows down | Because the two clocks stop at the same event, subtracting one from the other leaves exactly the time the item spent waiting to be started. On most teams that remainder is the larger of the two numbers, and it is completely invisible to a team that tracks only cycle time. ## A worked example A team building a construction-site safety product measured, across one 3-week window, an average cycle time of 4.2 days and an average lead time of 23.6 days. Nothing about those two figures is contradictory: 19.4 days of the average request's life were spent queued before anyone picked it up. The founder reordered priorities most weeks, so anything not near the top of the queue kept getting pushed back while freshly arrived requests jumped ahead of it. Every item, once started, still cleared in a little over four days. Report cycle time alone and this team looks fast. Report lead time beside it and the real conversation surfaces: the constraint is not how the team works, it is how much work is admitted and how often the order is rewritten. ## Pinning down the endpoints Teams genuinely disagree about these definitions, so an interviewer usually cares more that you state yours than which variant you chose: - **Where "accepted" begins.** The moment a request is admitted as work the team will actually do. Counting from the first vague hallway conversation makes lead time unfalsifiable. - **Where "started" begins.** The moment the item is pulled into the first active stage. If a column named "ready" is really a parking area, work has not started and those days belong to the queue. - **Where "delivered" stops.** Pick one endpoint and keep it. Stopping the clock at "ready to release" hides whatever release queue sits behind it; stopping at "available to a user" includes it. - **Which days count.** Calendar days are the honest default, because a requester waits through weekends too. A working-days variant is fine as long as every reader knows which one the number is. - **Blocked time counts.** An item blocked for six days took six more days, whatever the reason, and hiding that makes the metric useless for spotting the reason. ## What good answers sound like - Name both clocks and their start points before comparing them. - Point out that they share a stop event, so the difference between them is queue time. - Say which one you would show a stakeholder (lead time, because it is the wait they feel) and which one you would use to judge a change to the workflow (cycle time, because it isolates the team's part). - Note that a single average of either is a weak summary, because both distributions have long right tails. - Refuse "our cycle time is two days" as a standalone claim — the number means nothing without its boundaries. A team whose cycle time falls while its lead time climbs has improved nothing that a requester can feel. That sentence is the entire reason both measures exist, and it is usually the point the interviewer is fishing for.