Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,467,810
Community Members
 
Community Events
177
Community Groups

Status Changes in Jira

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. 

jql.png

 

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}}

image-20210916-004807.png

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.

image-20210916-010200.png

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

image-20210916-011854.png

18 comments

Darryl Lee Community Leader Sep 15, 2021

This is pretty amazing @Curt Holley !

Velizar Borisov Community Leader Sep 16, 2021

That's amazing! Exactly what we needed!

Thank you, Curt!

Mykenna Cepek Community Leader Sep 16, 2021

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?

Like Bill Sheboy likes this
Curt Holley Community Leader Sep 16, 2021

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 

Like Mykenna Cepek likes this

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

Like Curt Holley likes this
Curt Holley Community Leader Sep 16, 2021

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.

take 2.png

Like # people like this

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 Community Leader Sep 16, 2021

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.  😊

Like # people like this
Darryl Lee Community Leader Sep 16, 2021

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 statusBut 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 ;-}

Like # people like this
Curt Holley Community Leader Sep 16, 2021

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

Next phase though for sure!!!

Mykenna Cepek Community Leader Sep 17, 2021

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.

Like # people like this

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. 

Like # people like this

@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 Community Leader Sep 17, 2021

@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).

Like # people like this

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

Mykenna Cepek Community Leader Sep 17, 2021

@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?

Like Rich Wolverton likes this
Curt Holley Community Leader Sep 17, 2021

@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.

Like # people like this
Curt Holley Community Leader Sep 17, 2021

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.

Like # people like this

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events