Comment by vasco
6 months ago
If all things considered within cycle time - as you correctly say - indicate a developer's forecast for delivery timelines, and one developer over a large enough period of time working on the same codebase has half the cycle time as another, does that really tell you nothing?
Assume you're in a team where work is distributed uniformly and not some of this faster person only picking up small items.
No, it doesn't tell you anything. Someone is consistently delivering half the tickets compared to another person. Are they slow, lazy or etc? Or are they working on difficult tickets that the other person wouldn't even be able to tackle? Cycle time doesn't tell you anything about what's behind the number.
> Someone is consistently delivering half the tickets compared to another person
So it does tell you something. You also nicely avoided the condition I gave you which is, the team picks up similar tickets and one person doesn't just pickup easy tickets. Assume there's a team lead that isn't blind.
Work is never distributed uniformly, that's a silly assumption.
You've misunderstood: cycle time is neither a forecast nor a measure of individual productivity.
Cycle time measures how long it takes for a unit of work (usually a ticket) to move from initiation to completion within a team's workflow. It is a property of the team / process, not individuals. It can be used to generate statistical forecasts for when a number of tasks are likely to be completed by the team process.
For most teams, actual programming or development tasks usually represent only a small portion—often less than 20%—of the total cycle time. The bulk of cycle time typically results from process inefficiencies like waiting periods, bottlenecks, handoffs between team members, external dependencies (such as waiting for stakeholder approval or code review), and other friction points within the workflow. Because of this, many Kanban-based forecasting methods don't even attempt to estimate technical complexity. They focus instead on historical cycle time data.
For example, consider a development task estimated to take a developer only two days of actual programming. If the developer has to wait on code reviews, deal with shifting priorities, or coordinate with external teams, the total cycle time from task initiation to completion might end up taking two weeks. Here, focusing on the individual’s performance misses the bigger issue: the structural inefficiencies embedded within the workflow itself.
Even if tasks were perfectly and uniformly distributed across all developers—a scenario both unlikely and probably undesirable—this fact would remain. The purpose of measuring cycle time is to identify and address overall process problems, not to evaluate individual contributions.
If you're using cycle time as an individual performance metric, you're missing the fundamental point of what cycle time actually measures.