We find most organisations and teams who want to understand their time to value need a metric to measure the average elapsed time a ticket takes to move through their process all the way into their production environment. When using only data from your ticketing system, often a ticket being in its final 'done' status doesn't reflect it then waiting to be deployed to production.

Our Delivery Time metric allows that time a ticket is "Awaiting deployment" to be added on the end of the ticket status time to measure the full lifecycle of your delivery. By calling our Pipeline API Plandek will have information about your production deployments and via commits and references to tickets, we can calculate the deployment date of each ticket. Similar theory to Pull Requests in our Code Cycle Time metric, where we can calculate the deployment of a given PR.

However, not all completed tickets or PRs will be deployed when looking at the most recent data. Therefore, you can 'filter' these metrics to only tickets or PRs that have been deployed using the below tickbox (and hitting save). This ensures that the average durations include only tickets or PRs that have completed their full lifecycle.

Example (delivery time)

Below is a standard delivery time chart showing a stacked bar of statuses over time (by ticket completed date). The light blue at the bottom of each bar shows the average time to deploy, but as we can see in the last 4-5 weeks there hasn't been a deployment. Also across the whole chart we have data for tickets that have never been deployed, and this is skewing the average time down to 6.3 days.

Once we limit the same data to only show tickets that have been deployed, then we see that time "Awaiting deployment" has a much bigger impact on the overall process and the mean average is lifted to a more realistic 20.9 days.

Lastly, we can note that some tickets (circled in red) have been deployed, but don't have any "Awaiting deployment" time. This is because the deployment in these cases where before the tickets were moved to Done, therefore we reflect the time in the previous status prior to Done.

Did this answer your question?