Sleuth is pleased to announce a new option to start your Change Lead Time clock based on state transitions in your issue tracker!
In our ongoing effort to meet customers where they are, we heard from many of you that you’d like Sleuth to account for and provide visibility into your pre-commit coding time. We’re pleased to offer this this new option to tell Sleuth which specific state transitions in your issue tracker should start your Change Lead Time clock!
The Lead Time Debate
The "right time" to start the clock on Change Lead Time is a hotly debated topic. At one extreme, some argue that CLT shouldn’t start until the point of merge, providing a laser-focus on your CI/CD process and identifying its specific bottlenecks. Others suggest that Change Lead Time should be tracked from the moment the business requests a change (sometimes referred to as “Cycle Time”), as this measure provides a more realistic picture of how long it actually takes teams to respond to change requests. It also provides visibility into additional bottlenecks that might be impacting review time, review lag time, coding time, and even time spent on prioritizing and grooming change requests.
At the end of the day, the debate is largely an academic one. Here at Sleuth, our focus is on helping teams identify opportunities to improve, and in order to do that, we believe teams need:
- The ability to define metrics in whatever way best aligns with their unique objectives and processes for achieving them
- Wide visibility for identifying CLT bottlenecks across their delivery chains combined with the ability to drill down deep into any specific phase in order to identify the root causes of those bottlenecks
Historically, Sleuth has defined Change Lead Time as starting from the moment of first code commit. We believe this definition aligns best with the original intent set out by the State of DevOps report, and we’ve seen that, especially when combined with Sleuth’s powerful drill-down capabilities, it provides our customers with the breadth and depth they need to identify opportunities to improve their software delivery performance. As such, this definition remains our recommended one for most customers, and it continues to be the default setting for new and existing projects in Sleuth.
However, for engineering teams that spend a significant amount of time in (and have the authority to affect changes to) their issue tracking workflow, we see great value in enabling those teams to expand their CLT scope to include it.
With this latest release, customers can now:
- Enable and configure issue-initiated CLT on a project-by-project basis using any of Sleuth’s supported issue tracker integrations (Jira, Linear, GitHub, GitLab, Bitbucket, Azure DevOps, Shortcut, and more to come!)
- Specify which issue states from their issue trackers should start the CLT clock
- See all “issue created” and “issue state transition” events on the Deploy Details Timeline
- Filter and sort the Deploy Details Timeline to bring more or less attention to these new issue-triggered events
More issue tracker goodness to come!
This is only the first in a line of upcoming enhancements focused on bringing customers more visibility into their issue tracking process and its impact on their DORA metrics. Stay tuned for additional charts and dashboards that will provide visibility into issue breakdowns (e.g. by issue type, by issue status, by number of related PRs, etc.) as well as early-and-actionable visibility into issue-related risks impacting your current work-in-progress!
