Status Changes in Jira

[#1]

In recent times I've had a number of people ask me "How can I see how long a story spent in each status?" and things like that.

Sending them into the history of a story to work it all out themselves is hardly an appealing proposition.

So I started googling for options and come across this: 

Quick and easy way to create a "Days in Status" field for Jira Server or Cloud - Public Knowledge Base - Confluence (atlassian.net)

Which is great!! but I decided to enhance it so that all status changes could be recorded in a “StatusChanges”(Paragraph) field that I found in our Jira instance that had not been used.

Here is what I've done:

Created "Days in Status", "Last Transition Occurred" and "Last transition status" fields as per the above link. Note: the "Last transition status" field isn't really needed, but it is useful if you wanna show the last transition and time via JQL or on a Confluence page. 

For the automation

Using {{#changelog.status}}{{fromString}}{{/}} to provide the previous status

As well as updating the Days in Status field using:

{{now.diff(issue.customfield_10299|now).abs.businessDays}}

At the same time the StatusChanges field is updated:

• The {{issue.customfield_10115}} part of this copies the existing content of the field back into what is otherwise an overwrite of the fields content.

• {{now.diff(issue.customfield_10299|now).abs.businessDays}} is a copy of what is going into the “Days in Status” field, but making it visible.

I then created a 2nd automation rule set to run after the 1st Rule. It simply refreshes the Last Transition Occurred field for that issue, so that it is ready for the next Status changes populator (the !st Rule) run and can record the transition so that the  {{now.diff(issue.customfield_10299|now).abs.businessDays}} is accurate.

The net result being a paragraph field that updates in real-time, the journey of each issues Status changes as measured in business days.

[Darryl Lee]

This is pretty amazing @Curt Holley !

[Velizar Borisov]

That's amazing! Exactly what we needed!

Thank you, Curt!

[Mykenna Cepek]

Very cool, @Curt Holley

It looks like each transition adds a new line to the text field - is that correct? So if an issue transitions back to a previous status, then that status will be mentioned again. Do I have that right?

I'm also wondering why you ended up needing the second rule. My intuition suggests that editing the issue twice didn't work properly, since you needed the "Last Transition Occurred" field in order to do the date computation. Or did you encounter something else?

For that situation, I was wondering if you tried saving that value early in the rule in a variable, so that you'd only need one "Edit Issue" component? Would that have worked to avoid the second rule?

[Curt Holley]

HI @Mykenna Cepek you are right on all fronts.

All transitions are recorded and added in sequence to the StatusChanges field. Yes, the 2nd rule is simply a timing thing. 

I like the sound of your variable suggestion and variables is one area of Automation for Jira that I haven't got to.....so I'm off to experiment now!!

Thanks!!

Curt 

[Rich Wolverton]

Outstanding and useful. There needs to be a reference library in the documentation and/or community space that consolidates material like this. 

[Curt Holley]

STOP THE PRESS

Thanks @Mykenna Cepek for the variable inspiration. This is why I love this Community ❤

By creating a variable {{LastTransitionTime}} out of 

{{now.diff(issue.customfield_10299|now).abs.businessDays}}

The 1st Rule can now do it all, by using the variable as follows and finishing the rule with the update to {{now}} on the Last Transition occurred field....job done in one automation rule.

[Steven Haworth]

This is great work!  So - how are you using the information?  Are there actions taken based on how a Story (for example) remains blocked, or something?

[Curt Holley]

HI @Steven Haworth 

I'd like to think it will be used to (if/when required) analyse where in the workflow the hold-ups are, which can lead to conversations about why. As well as how to fix moving forward.

Particularly handy for Kanban teams with many workflow statuses.

At the end of the day, I just build it. That said, I do still see it as a lag indicator and if the team don't know/understand where their blockages are without a paragraph about it in every Jira issue....as written by automation, then they may well have an issue bigger than Jira can solve.

But it has been fun working out how to do it, refining it and ultimately getting down to one automation rule.  😊

[Darryl Lee]

So I could think of a use. Instead of buying the venerable Time in Status add-on that we all know and love, you could spend the money on one of the fancy graph/report/charting add-ons out there, and use this data to create your own charts.

Well, it wouldn't exactly do everything Time in Status does. You'd have to extent Curt's work with additional fields to track the total time for each status. But still, you maybe probably could do it! You know, for fun. :-}

But seriously, this is a really cool stuff, @Curt Holley ! And great code review from @Mykenna Cepek ;-}

[Curt Holley]

Love it @Darryl Lee  but that is more fun than I can handle today 😂

Next phase though for sure!!!

[Mykenna Cepek]

I was thinking the same thing, @Darryl Lee. Creating a custom field for each Status in an instance doesn't sound fun, but it would allow for more reporting. Probably would want to accumulate the time more granularly than "days" (seconds seems overkill, if native; minutes or hours?).

But then I remembered that the Cumulative Flow native report in Jira does aggregate exactly this "time in status" data. So this data is already in Jira somewhere (even Cloud). That just made me grumpy, since even a Feature Request to access that data would be useless, as it would eclipse a Marketplace app.

In fairness, the "Time in Status" app does more than just this, and it's relatively reasonably priced. I'm just torn between "I cannot justify the additional expense of another app" vs "I can't access data that I know is just sitting there".

@Curt Holley's approach here allows those of us with the skills, time, and motivation to at least make a little progress.

[Mykenna Cepek]

I don't want @Steven Haworth's question above to get lost in this thread, as I think it's a good one:

...how are you using the information?  Are there actions taken based on how a Story (for example) remains blocked, or something?

@Curt Holley, in your OP you wrote that your users had asked you for this data in Jira. So you were responding to that request.

But when wearing my Agilist hat, I take Steven's point -- how, specifically, will this help your team(s)? Just wondering, Curt, if your teams had some specific use for the data (other than curiosity)? UPDATE: I missed Curt's earlier response to Steven's question (sorry!).

The "Cumulative Flow" diagram is helpful as a high-level aggregate. But hovering over the data points in that diagram is a poor way to "drill down" for detail. The "Time in Status" app fits neatly into that middle-ground, and improves the visualization of the data.

I can also see that Kanban teams that might be paying attention to the "Control Chart" might be able to use Curt's approach to diagnose outliers. 

[Rich Wolverton]

@Curt Holley Unless I am missing something there is a catch. 

• This requires the automation-for-jira plugin for Jira Cloud
• The automation-for jira plugin for Jira Cloud is not available
• There is a significant disclaimer on performance in the linked video

[Mykenna Cepek]

@Rich Wolverton: The app/plugin is no longer necessary. Automation has been incorporated into the main Jira Cloud product as a standard feature (also available in JSM as well).

This automation functionality was originally created in app form by Code Barrel. But they were acquired by Atlassian in late 2019 (link).

[Rich Wolverton]

@Mykenna Cepek Thanks! This is good news. Is there still a performance concern for large installations?

[Mykenna Cepek]

@Rich Wolverton Honestly, I don't know about performance issues with Automation for large orgs.

I would think that pulling the technology in to be Jira-native would allow those kinds of issues to be better addressed (rather than within the limitations of a Marketplace app).

Can those using Automation at large installations offer any feedback on performance concerns?

[Curt Holley]

@Rich Wolverton  I've never encountered any performance issues...not that I'm in that large a company (in the grand scheme of things). But it does have a throttle that it may deploy if you go crazy with a scheduled job. I find keeping automation real-time keeps it all under control.  I have done some large bulk update type jobs via a schedule and also never had any performance hits.

[Curt Holley]

For the record: I've done one final enhancement. Local time zoning the Last Transition occurred field/variable entries.....so the days are aligned with the users perceptions/expectations.