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:
Let’s have a closer look…
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.
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?
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:
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.
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.
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:
Exporter offers all transitions as single rows within the same issue.
Once the data live in Excel, creating business insights only takes a couple of formulas.
Using the Countif complex condition and the average complex condition functions, slicing the dataset by, say, issue type and workflow status is straightforward. You can see exactly how to do it with our transition audit template.
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:
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.
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.
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.
Download the spreadsheet below to get a full template with all the calculations you need to audit transition times in your Jira instance!
No Comments Yet
Let us know what you think