From To Do to Done: Analyzing Time Duration Between Statuses

[#1]

Monitoring the time between statuses can provide valuable insights into your team's performance, identify bottlenecks, and improve the overall workflow. It can help answer questions such as:

• How long can a reported bug be assigned to a developer (transition from Open to In Progress)?

• What is the average time it takes for a developer to fix a bug (transition from In Progress to Ready to release)?

• How long can a fixed bug be verified and closed (transition from Ready to release to Done)?

Why should I measure the time between statuses at all?

Look at the questions above. You realize that they require answers. And those answers may even be helpful. But why? Why do I need to know these or those metrics - it's still working. Projects are done, bugs are fixed, and tasks are closed. I'm not interested in anything else. If there is a delay somewhere, it's not critical. There is a severe blocker, and a fire is already burning from long-overdue deadlines - well, not for the first time.  

What if we could prevent all these problems and stop living one day at a time?  

So, what can we do if we have answers to these questions?

1. Resource Allocation. Knowing how long a reported bug can be assigned to a developer (transition from Open to In Progress) helps with resource allocation and project planning. If bugs remain in the open state for too long, it might indicate bottlenecks or resource constraints that need addressing.
2. Efficiency Monitoring. Understanding the average time it takes for a developer to fix a bug (transition from In Progress to Ready to release) allows you to monitor your development team's efficiency. It helps identify where developers might need additional support, training, or resources to speed up bug fixes.
3. Release Planning. The duration it takes to verify and close a fixed bug (transition from Ready to Release to Done) is critical for release planning. It provides insights into the overall release cycle duration and helps set realistic timelines for product updates and releases.
4. Process Improvement. By tracking these metrics over time, you can identify patterns, trends, and areas for improvement in your development process. For instance, if the average time to fix a bug increases, it may indicate the need for process optimization, better tools, or enhanced collaboration among team members.
5. Customer Satisfaction. Timely resolution of bugs enhances customer satisfaction. Understanding and optimizing bug resolution times contribute to delivering a more stable and reliable product, ultimately leading to happier customers.
6. Quality Assurance. Monitoring the lifecycle of bugs provides insights into the effectiveness of your quality assurance processes. It helps identify areas where testing procedures can be improved to catch bugs earlier in the development cycle.

Incredibly, just one numerical value can open your eyes to many nuances that need attention.

Measuring the time between statuses

For this process, let's consider the Time Between Statuses app. 

The basis of the app is the formation of status groups, according to which the calculation of various parts of the process, or workflow as a whole, will take place. 

How do you choose the correct statuses for calculations? 

Group statuses are configured within the project, so to select the correct statuses, go to the project, where you will calculate and open the workflow scheme.

Try to conditionally divide the workflow into segments that you want to measure. There is no single canon. Everything is individual and unique to your workflows, experience, and specifics. For example, we divided it like this:

Next, configure these group statuses in the Time Between Statuses app. 

Choose which transfuses are taken into account in the calculation. We can also add a status when the time will not be counted. In this case, the On hold status was selected. 

Also, you can set specific time limits so that the application notifies you with notifications that a particular task is in a certain status for a long time. This way, you can keep up with all the processes without constantly being in the app.

After you have configured all group statuses, we recommend setting up a work calendar so that weekends or off-hours when there is no activity on tasks are not considered.

Next, you can proceed to generate a report. Select the project and task types (in this case, Bug and the time period you want to see the calculation). You can also generate a report for a separate assignee, label, status, or sprint within the selected project.

We have measurements for all four status groups we previously configured on the report.

In the Testing Time status group, we have configured the color highlighting of the warning and critical time limits, which we can see on the grid.

After analyzing the report, we can see that some bugs have been in the To do status for too long and still need to be fixed. Some were fixed quickly enough but got stuck at the testing stage.

A complete analysis provides insights on how to reallocate resources, etc.

Takeaway

To summarize. To calculate the time between statuses correctly, you need to follow a few critical steps:

1. Properly build the workflow and define the statuses.
2. Hold a meeting with the team and ensure that you are on the same page with them and clearly understand how tasks should move between statuses - what the sequence is and what each means.
3. Distribute the statuses among the groups where you are most interested in measuring the duration.

And... try to use the Time Between Statuses app for calculations. For you, it is 30 days of the trial. The app is available for both Jira Cloud and Jira Data Center.

Have a great day! And don't let the bugs be critical 😉