Cycle Time Breakdown: Tactics for Reducing Coding Time

The Issue: My Coding Time Feels Too High

Cycle Time is the Dev Manager’s Super Metric. So naturally, the conscientious Dev Manager will want to pay close attention to Coding Time, the very first segment of a project’s journey along the Cycle Time path. Keeping Cycle Time “all green” is the goal, but this is often difficult because there are a lot of moving parts that go into managing Cycle Time. One of those moving parts that are hard to keep in control of is Coding Time.

Coding Time is defined as the time between the first commit made to a branch to when a pull request is submitted. As a general rule, you want your coding time to be two to three days. Anything above four days is considered worrisome, and a Coding Time above seven days is a real problem. Many elite teams are able to measure Coding Time in hours, not days.

In the past, we could measure the notion of Coding Time only anecdotally. Perhaps you could keep track of how the coding on a project was going by the reports in a daily standup.

However, these days, managers are demanding more — they want hard data. LinearB provides an overview of Cycle Time for all your projects on the main dashboard that includes a clear indication of the status of your coding time. This dashboard is…