Companies do projects. Sometimes – a lot of projects. If a company is managing their project with the help of Jira – this is already half of the win. However, Jira, as powerful as it is, has a lot of ways to manage projects, so every company needs to think before setting up their project management in Jira. Yeah, you can go with the standard project templates if they work for you. But more often than not, they won’t. So, you will need to customize them, and the custom workflow is usually the place to start. A custom issue hierarchy, using Advanced Roadmaps, is also common these days, especially if your company and project size are above the one figure numbers. When you factor the different issue types, the hierarchical order and the various workflow steps they should pass to finish a project, it can all become a little too much to handle manually, ticket by ticket. Luckily, Jira Automation comes to the rescue, and in this article, I will show you a glimpse of how it can make the life of a Project manager easier.
It is quite common that projects get stuck for all kinds of reasons – stakeholder decision, technical obstacles, market situation, etc. So almost all Project workflows I have seen have a status like “On Hold” (or should have). Let’s go with the following sample setup:
Now, what happens if your Project needs to be put “On Hold”? Obviously, you need to put all issues under that project to “On Hold”, so that all your teams (dev, QA, BA, DevOps,…) know that their tasks for this project are currently stopped and they should switch to doing something else. As Project Manager, you have several options – go through each issue and change its status to “On Hold” or if you are JQL nerd – do a query like “issue in childIssuesOf(Project issue here)” and then bulk change the status of all found issues to “On Hold”. Here is how to do it with a simple automation rule:
As trigger you would use the status change of your Project issue and then branch on the Project children using simple JQL and put all that are not finalized to “On Hold”. Simple, right? Now comes the fun part – how do you resume the Project where it stopped? When you want to resume your Project, you don’t want to start everything from the beginning, right? If a Story was in status “In Review”, you need it to proceed from that status, for example.
So how do you do that?
Obviously, you need to have the status of each issue before it was put to “On Hold” stored somewhere. Here comes Jira Automation handy again with the following simple rule:
Here you trigger the rule when the status of issue changes and using the smart value {{fieldChange.from}} simply store the name of the previous status in a text custom field, called “Previous status” (make sure you have such field and it is applicable for all your issues under the Project).
Now that you have your issues in status “On Hold” and in each issue you have stored the previous status, it is easy to use Jira Automation again to resume your project by using the following simple rule:
Here you trigger the rule when your project is moved from “On Hold” status to where it was. Then you branch using the same JQL to get all the children issues of the Project and if their status is “On Hold” – you transition them to the Previous status, that was stored before. And suddenly your Project comes back to life where it stopped, all your teams see their tasks active again and can resume their work.
I hope this article shows you how 3 simple Automation rules can save a ton of manual work for a Project manager. Use Automation wherever you can to make your life in Jira easier!
Boyan Angelov (Nemetschek Bulgaria)
Atlassian Solutions Leader
NEMETSCHEK OOD
Bulgaria
45 accepted answers
1 comment