Jira Workflow Best Practices III

Author: Ismael Jimoh

Thank you once again everyone for reading the third part of this blog series. We hope you found the earlier blogs useful. In this final instalment, we will be looking at:

• the benefits of reusing Statuses that you have created,
• or even using the same workflow when you have identical processes,
• clarifying the benefits and risks of allowing teams to administrate their processes,
• and also some of the functionalities provided by Atlassian that help teams get more done via automations, and
• the benefits of Versioning our workflows

Sharing is Caring

As the old adage goes, “You can walk fast, when you go alone, but you go further, when you go in a group.” And just like this adage, it’s also true of your JIRA instance. For every re-used status, the less mess you have to clean up, the more sensible your statuses are, and the less performance impact the number of statuses have on your JIRA instance health in general.

Similarly, the more projects that share a workflow with multiple projects, using either the shared configuration provided by the application or associated with your existing project workflows with the new project’s Workflow Scheme, the cleaner the instance. There are of course scenarios in which creating a new workflow is mandatory. Take for example, when the project process of two projects diverges with one project or an issue type needing an extra step that would not be present in another. However, whenever it is possible to share workflows, you should take the opportunity. (Note: With add-ons, we can work around this, however, the simpler workflows are, the easier it is to make sense of them and have stakeholder buy-in.)

With this, wouldn’t you agree that “sharing is truly caring”?

(Info) Read more here about Jira Workflow Schemes.

Power To The People

With the advent of team-based (next-gen) projects in Atlassian cloud, in addition to company-based (classic) projects, there has been a move to decentralize administration from just an elite group of people (Administrators). Democratizing project management allows teams to manage their own processes.

This leads to:

• individualism of teams;
• more satisfaction because changes can be made more quickly without having to wait for a JIRA Administrator. (Unfortunately for JIRA Data Center, you can only use statuses that have already been created).

This individualism also lets the administrator focus on other more important things, bringing JIRA in line with tools such as Trello and Asana, which have team friendly structure and configuration.

However, team-based projects are only available in Atlassian Cloud at the moment, and for those locally hosted on JIRA Data Center, we still have to partially delegate these powers. Here is where the Extended project administration permission comes in handy. It allows project administrators to edit the Workflows on the condition that the workflow is not shared and the user has the administer project permission. They still cannot create new statuses, but at least make use of already existing statuses which is where the creation of reusable statuses comes in earlier.

Adding to the above, as Atlassian Cloud gets a lot of the good stuff automatically integrated: there is Automation for Jira (paid for in DC although there used to be a lite version (traurig) ) which allows project administrators to build onto your working process flow using the various options it provides to automate specific actions when specific conditions are met. You can read more about project automation here and some more advanced uses here.

For example, the automation rule below adds a comment to an issue when it’s created. It specifies in the comment the exact time the issue was created:

As nice as this is, you still have to note that a fully democratized instance in which everyone has free rein to create the workflow statuses, resolutions and transitions they want, it would be a pain to clean up and quickly get unhealthy. Hence, as Uncle Ben once said to Peter Parker, “With great power comes great responsibility.” So, take the initiative to ensure power is also handed only to those who truly need and deserve it.

Version Everything

Ask any author; “What version of your story or article are you on? What happened to the old ones?”

And you are likely to get an answer like, “Version 6. No, make that Version 8. Well I had to modify the book after peer review, feedback from proof readers, it didn’t quite sound right…”

Have you ever considered asking a follow-up question such as what happened to all the old ones? Why did you rewrite so much?

And the simple answer is likely going to be, “I kept the old one as a reference and version #x of the final product. As to why I wrote so much, well the story grew or something changed, and I felt it didn’t add-up with the old process so I decided to rewrite it.”

Enough digression, here are simple reasons to version all things:

• It allows you rollback if you change your mind.
• It is a main reference when you need to look back at things or even audit a process, etc.

The versioning topic is even much more important when it involves our last point of delegating the ability to make changes to various users. Should a user make a change and states a version or even if they overwrite the last agreed change, you would always have a documentation highlighting the last agreed changes. This helps with rebuilding the workflow to how it is meant to be as per the version or even a direct rollback by updating the workflow associated with specific issue types to the prior version before the aforementioned change.

As Atlassian allows export of workflows, it may be advisable to consider exporting workflows in xml format and storing these in a repository such as Bitbucket or GitHub as these can help create a controlled environment in which you can reference the workflow in your documentation. These tools also handle versioning a lot better than just the typical version #1 or v1 that we may add to the names in Jira itself.

Now, the “elephant in the room”: How many versions should I keep? This largely depends on:

• How frequently your process changes
• How long your audit requires you to store old processes
• Validity of the old process (say there was a misunderstanding of what was expected and this was only realized at a much later date, then there is no point storing such a process further)

The general recommendation from me would be to:

• Review your Workflows and Workflow schemes every 6 months
• Backup and confirm you have backed up all versions of your prior workflows
• Delete any inactive Workflows and Schemes that have not been updated within this time period

Conclusion

This brings us to the end of the series. I hope you all have found some of these suggested best practices useful, though we understand and recommend that you look through them and apply them based on your team and organization’s requirements because they may not just suit your organization’s policies.

There are definitely many more topics we could talk about such as:

• cleaning up/maintaining the workflows which I briefly touched on above in the versioning section
• standardizing scripts and how they should be stored or even
• how to delegate who should have access to editing workflows

However, these are topics that are very dependent and vary from organization to organization. I would love to be able to go a bit more in-depth into them as a separate topic sometime in the future.

If you are just finding this series and would like to also read the earlier ones, please find the links below:

As for where to get support, I would recommend looking at the first blogpost as I went a bit in-depth there on where and how to get what support.

Thanks again for taking the time and we look forward to your feedback.

Originally published at https://kreuzwerker.de on March 8, 2022.