Transition audits are necessary to control and improve your time to market. Even in the most advanced DevOps culture or the best performing startup, barriers will slow down the product lifecycle stages. In this article we’re going to answer the why and the how.
Transition audits are essential in a product team by saying an example, but actually it should apply to every team using Jira. On this post we'll show:
How transition auditshelp team leads exceed business expectations by better understanding what’s harming their productivity.
How to audit your transitions in Jira Software with DEISER's Exporter. (The same applies to Jira Service Desk, only the context changes.)
Let’s have a closer look…
Velocity is volatile
You need to know your team velocity to plan for every work iteration and generate adequate expectations among stakeholders. But, alas! Velocity is a variable, not a constant. You cannot measure it once and take it for granted: Everything you do will change it.
I repeat: EVERYTHING YOU DO WILL CHANGE YOUR TEAM VELOCITY. Or at least it has the potential to alter it. And it’s not just what you do: what simply happens is as important.
That’s why you must take velocity for what it is: the most important metric of your productivity, but also the volatile result of dozens of concurrent factors.
Did you fail to recognize the complexity of a task? Boom!
Are your testers swapping context too often? Boom!
Internet connection slow? Manual work? Personal problems? Boom! Boom! Boom!
Atomic news: Your team will get less done.
Even if you think that your team is performing all right given its current capacity, you’d probably be surprised at how much you can improve if you find what’s holding you back from your maximum potential. But where do you start when you don’t know where your waste is hiding?
Discover the waste that is holding you back
Do you want to identify areas of stagnating collaboration that are slowing you down?
Would you like to improve your time to market? (Or rather: wouldn’t your CEO be happier if you did?)
If the answer is yes, this is where you start: by analyzing how long each piece of work lives in each of your statuses. In other words: audit your transitions.
Transition audits can be very helpful for analyzing compliance of your SLAS.
But for product teams, auditing transitions is a bit different: it doesn’t focus on response times, rather on the hand-offs and other critical points of collaboration where work can potentially sit idle.
These are some of the benefits of analyzing your transition times:
Measure exactly how long work is waiting for others to pick it up.
Adjust your WIP to reflect how much you can get done.
Understand exactly what is causing delays.
Example: Let’s assume that code reviews are starting around 1.5 weeks after the branch was submitted for review. The first problem is that code is rarely reviewed during the same sprint, so that, whenever there are any problems or clarification needs, the coder may not remember exactly what she did because she’s already working on something else. That’s a whole area that needs to be improved.
How to audit transitions with Jira
1. Looking at singular issue transitions
Jira records every transition of an issue, and the information is easily available at the main issue screen. That’s good news! If you ever wondered why a given issue took that long, you can trace its history.
2. Looking at average time per status
One way to get information about the transition times from every issue in a central location is with DEISER’s Exporter, which extracts all issue-related information in a single file. In comparison to other exporting add-ons, Exporter is a great fit for this task for the following reasons:
It includes transition data in different formats: initial date, end date, absolute time (both in seconds and in dd/hh/mm/ss.)
It offers all the raw data in an excel file that can be manipulated as needed.
Here are a couple of examples that I’ve created with fake data and the taxonomy that we use at DEISER for the development of our apps for Jira. These compound charts show two series of data:
The total number of issues that have gone through each status.
The average time that the issues spend per status.
Example 1: An imperfect approval process for stories
How long did it take to move stories from the Backlog to Done?
The purple line seems to stay flat throughout the process until it spikes in “Done”, as it obviously should in an end status where every story is fundamentally archived. But zooming in a bit it becomes quite apparent that the approval process could improve a little: stories are sitting waiting for approval for about a month. It’s now time to go deeper and find out what could be done to accelerate this area.
Of course, there may be outliers that are throwing off the stats. If you fear that your dataset is plagued with a small number of issues with extremely long transition times, make sure to account for them. You can exclude them from your analysis or simply calculate standard deviations. Excel charts can be customized to show them automatically.
Example 2: Focus on the spike or the valley?
In this case, we have an analysis of the transition times of all the releases – an important issue type that we use at DEISER. Again, remember that the actual data isn’t real.
The image represents faithfully code tasks in Bamboo: once the version has been deployed and we have the artifact, it’s automatically released.
I like this chart because it’s quite a dilemma: a team that faces this kind of insight will have to decide which area should be tackled next in order to improve time to market. Although deployment seems the obvious candidate, there might be quick wins in areas, like the approval time, that are taking the valley of the chart.
Dive into your data
Download the spreadsheet below to get a full template with all the calculations you need to audit transition times in your Jira instance!
Discover how productive your team is
Follow steb-by-step instructions to audit your transition times in Jira with this transition audit template. Just paste your data and go!