What is the Issue Cycle Time?

Companies use this cycle time insight to monitor the ongoing delivery performance over the selected reporting period. It allows product managers to detect unusual shifts in the average duration of each stage and address delivery problems or slowdowns with the right team (developers, product designers, QA etc.).

This cycle time insight is a superior approach to using a burn-down chart, as it highlights which stage of the development cycle is causing problems instead of just showing a sudden blockage in the delivery pipe.

This insight also allows teams to experiment with new development patterns and monitor the results. Creating per-team variations of this insight allows engineering managers to perform A/B testing on development practices, giving them hard cold facts about what works and what does not.

Leading software companies (Netflix, Amazon, etc.) track the cycle time of issues to optimize development processes and ensure efficient workflow management.

For clarity purposes, this insight is broken down into 4 stages:

• Pickup Time is the total duration spent in the initial status before the development starts (e.g. “To Do”)
• Implementation Time is the total duration spent in the development status (e.g. “In Progress”)
• Quality Assurance (QA) Time is the time it takes to verify that the implementation matches the business objectives (e.g. "In Testing", "In QA")
• Release Time is the time it takes to move the issue to production (E.g. "Ready to Release", "Pending Release Approval").

The statuses for each stage can be customized to match your Jira/Trello workflow configuration. More stages can also be added to increase the cycle time granularity.

Key Benefits of the Issue Cycle Time Overview for Jira and Trello

• Identify Bottlenecks: Pinpoint stages in your workflow where delays frequently occur. This insight helps in addressing and mitigating bottlenecks, improving overall process efficiency.
• Improve Estimations: Enables better estimation of task durations, leading to more accurate project timelines and resource allocation, enhancing your team's planning and forecasting capabilities.
• Measure Performance: Evaluating team performance and productivity. By setting benchmarks and analyzing trends over time, you can identify high-performing areas and those requiring improvement, ultimately boosting team efficiency and output.
• Ensure Transparency: Fosters transparency within the team and with stakeholders by providing a clear picture of progress and potential delays, facilitating better communication and collaboration
• Optimize Workflows: Refine and streamline workflows based on data-driven decisions to reassign tasks, adjust priorities, and implement process improvements, leading to more efficient operations.

How to Improve on this Metric?

Pickup time is high

This may indicate that issues are moved out of the backlog into the "To Do" state too soon. It can be tiring for developers to see a never ending "To Do" column, which keeps piling up.

Make sure to adapt the number of items to be picked up based on the throughput of your team. This will also give more time to your product managers to refine issues before they are put into development.

It may also indicate that the scope of issues is unclear. Developers tend to leave issues they are not sure about into the "To Do" state, until clarifications can be provided. In this case, try to involve engineers into the scoping of issues early on to ensure that the scope makes sense to them at a technical level.

Implementation time is high

A high implementation time may indicate that issues are too large or too complex to implement. In this case it may be worth transforming them into an Epic with smaller tasks. This will result in a more fluid development flow.

A high value may also indicate that engineers are busy on parallel tasks, such as support activities, peer reviews, mentoring etc. In this case it may be worth reviewing the distribution of work between engineers and other members of the team. Can certain tasks be automated to avoid the involvement of engineering?

QA time is high

A high QA time usually indicates a lack of testing automation. The QA team is constantly busy redoing regression testing on a large set of functionalities whenever a new feature is pushed.

If testing automation is not an option (yet) then it may be worth better isolating products and technical components so as to allow the QA team to only perform partial regression testing, which is much faster to perform.

A high value may also indicate that issues are too large and complex to test. In this case it may be worth breaking down issues into smaller tasks that can be easily tested in isolation.

Release time is high

A high release time indicates some slowness in the final preparation tasks before an item is set live. These preparation tasks may be related to deployments, deployment coordination (e.g. dependencies between releases), management approval, pre-release documentation etc.

In this case it may be worth analyzing those post-implementation tasks to evaluate if they (1) add value to the process and (2) if they can be shifted to regular implementation tasks (e.g. documentation).

It may also be worth reviewing the people in charge of those release tasks and make sure clear roles are assigned to people so that there is no ambiguity on who should perform those (pre-)release tasks.