Cycle Time as a Metric: Misinterpretations and Proper Use
Many commenters argue that cycle time is often misinterpreted and misused, particularly when applied to individual developer performance. Instead, it should be viewed as a system-level metric that highlights process inefficiencies, bottlenecks, and other systemic issues.
- "I've never encountered cycle time recommended as a metric for evaluating individual developer productivity, making the central premise of this article rather misguided." (tmnvdb)
- "The primary value of measuring cycle time is precisely that it captures end-to-end process inefficiencies, variability, and bottlenecks, rather than individual effort." (tmnvdb, quoting octo888)
- "It's borderline cruel to take cycle time and measure and judge the developer alone." (octo888)
- "If you're using cycle time as an individual performance metric, you're missing the fundamental point of what cycle time actually measures." (tmnvdb)
Several commenters elaborated on the systemic factors that contribute to cycle time beyond individual developer performance.
- "Waiting for responses from colleagues, slow CI pipelines, inefficient local dev processes, other teams constantly breaking things and affecting you, someone changing JIRA yet again, someone's calendar being full, stakeholders not available to clear up questions around requirements, poor internal documentation, spiraling testing complexity due to microservices etc. The list is endless" (octo888)
- "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." (tmnvdb)
Cycle Time's Relationship to Process and Bottlenecks
The discussion emphasizes that cycle time is heavily influenced by the overall development process, highlighting potential bottlenecks and inefficiencies. * "Not only does cycle time form a very poor measure of individual productivity, using cycle time to measure individuals will create very bad incentives that will make your team perform significantly worse!" (tmnvdb) * "The primary value of measuring cycle time is precisely that it captures end-to-end process inefficiencies, variability, and bottlenecks, rather than individual effort. This systemic perspective is fundamental in Kanban methodology, where cycle time and its variance are commonly used to forecast delivery timelines." (tmnvdb) * "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." (tmnvdb) * "... rather than the org acknowledging their processes are inefficient." (to11mtm)
Uniformity of Work Distribution and the Problem of Comparisons
The discussion reveals skepticism about whether distributing work is even possible and discusses the difficulty of comparing developers by cycle time.
- "Work is never distributed uniformly, that's a silly assumption." (hobs)
- "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." (Etheryte)
Queue Size, Variability and Alternative Metrics/Approaches
The importance of queue size and managing variability in the development process are raised as factors significantly impacting cycle time. Reinertsen's "The Principles of Product Development Flow" and actionable agile metrics are recommended. Several users discuss queueing theory.
- "And third, queue size plays a larger causal role in downstream economic problems with products. This is why you should always consider your queue size before your cycle time." (wry_durian)
- "I recommend looking at some Kanban literature. Classic in this space is Actionable Agile Metrics for Predictability." (tmnvdb)
- "Every day an item ages in your queue, you know the cycle time had increased by one day. Hence the advice to track item age to control cycle time." (tmnvdb)
- "(In the testing context, this could look like testing at a higher level of integration.) This adds variability to the process but you will learn more and faster, which typically results in economic upside." (wry_durian)
- "You could also just read a queuing theory textbook and try to generalize from it (and that's where you'll read plenty about high-capacity queues, for example)." (wry_durian)
Estimating Software Development Time
The challenge of accurately estimating software development time is brought up.
- "What I can't understand is why my intuitive guess is always wrong. Even when I break down the parts, GUI is 3 hours, Algorithem is 20 hours, getting some important value is 5 hours... why does it end up taking 75 hours?" (resource_waste)
- "Hofstadter's law." (pieterr referencing wikipedia)
- "If it's really important to have an accurate estimate for a large work package you are in trouble, there is no such thing." (tmnvdb)
- "Because "GUI" and "Algorithm" are too big. You have to further decompose into small tasks which you can actually estimate." (jyounker)
The Problematic Use of Comments per Pull Request as a Collaboration Metric
The researchers' idea of using "comments per PR" as a collaboration metric is criticized.
- "Comments per PR [...] served as a measure to gauge the depth of collaboration exhibited during the development and review process." (SiempreViernes)
- "That sounds like a particularly poor measure - it might even be negatively correlated. I'm worked on teams that are highly aligned on principles, style and understanding of the problem domain - they got there by deep collaboration - and have few comments on PRs." (duncanfwalker)
- "It gels with my personal experience where controversial changes in a PR gum up the works and trigger long comment threads and meetings." (tangotaylor)