Accelerate Jira Resolution Time

Why Is It Important?

The faster an issue can be resolved, the faster a new release can be made, such as pushing out a new feature, making a bug fix, deprecating old functionality, or improving application accessibility.

What KPI Should You Track?

The key KPI to track this is the “lead” or elapsed time between when an issue was created and when it was resolved. The time begins being tracked when a ticket status is marked as “In Progress” and ends when the last Pull Requests associated with it gets released, or when the ticket is resolved. Therefore, the smaller the lead time, the better the resolution time.

What Are The Underlying Metrics?

There are four key metrics that influence the lead time. These are:

• Average release frequency per day. Depending on the average number of PRs in a release, this metric gives a good indication of how quickly issues are being resolved.
• The number of Pull Requests created. Allowing for the number of contributors and the average PR complexity, the higher the number of PRs created, the longer the Jira resolution time will be. While PRs can be of any size, work to ensure that PRs are as small and as focused as possible.
• The number of contributors. The higher the number of contributors, regardless of skill or seniority, the faster your team can progress through the available PR backlog and the lower the average Jira resolution time will be. Ensure that junior contributors are being mentored by more senior contributors and that knowledge is spread across the entire development team.
• The proportion of pull requests mapped to Jira tickets. The lower the proportion of Jira tickets mapped to pull requests the lower the Jira resolution time will be. However, if issues are not mapped to PRs, then the resolution time will be misleading, giving a false sense of progress. While ultimately higher, ensure that all Jira issues are mapped to an implementing PR.

How Do You Accelerate Jira Resolution Time?

There are four key ways to do so:

1. Reduce pull request size. Doing so makes code reviews easier and quicker, as the number, complexity, and implications of the changes made is reduced.
2. Minimize the time Pull Requests remain idle. The longer a Pull Request remains idle, the higher the chances there will be merge conflicts from related PRs, and the changes will become outdated or fall out of alignment with the project’s goals. 
3. Encourage knowledge sharing and avoid human bottlenecks. Ensure that no one person is solely responsible for a single area, such as only having one release master or one person who knows all about a given set of functionality. Doing so builds skills within the team and increases the bus factor, thereby reducing risk across the project.‍
4. Ship smaller and more often to shorten feedback loops. Because they contain fewer new features and changes than larger releases, smaller releases are easier to complete. There are fewer changes to review, test, and validate. Because of the increased cadence, more lessons can be learned in a shorter period of time.