You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
We are using Plans extensively in Jira in the companies that I have founded to prioritise our backlogs and to assign issues to various execution teams like dev teams etc.
The dev teams like working with their Kanban boards and focus on the work items like stories while I as the product manager work with epics to prioritise what should be done when.
For our issues we are working with Goals->Initiatives->Epics->Stories->SubTasks.
When I work on setting Rank between epics I use the Hierarchy from epic to story. When I show this in our plans it is very easy to drag and drop epics to set the rank but the underlying stories are hard to rank since they are at a lower level than the epics.
We have some huge backlogs and over the years we have unfortunately started to work on some epics and their stories and then realised that the scope was too big and put the epics back on hold. Now a lot of work is being put into cleaning this and getting into a very short list of epics that should be worked upon.
The problem is that there are many stories in epics that are developed and ready for QA so I don't want to change the status of those stories to being back in the backlog status even though I want the epic to be in the backlog.
If it would have been possible in a filter to not include stories where the epics have status backlog it would have solved the issue but from what I could understand I need some paid extensions for doing that and I don't want to use that.
Instead we came up with a neat system using the shared teams in the plans. The team property is a custom field though and can even exist between various add-ons.
We use Tempo for example which has their own Team custom field and then the Plans have their own custom field for this purpose. That is the problem with having an open system :-) and obviously also a drawback in situations like this.
However, for our various engineering dev teams we set up a team each in the Plan and then a general Engineering team too. As responsible for planning I can then assign an epic to the Engineering team which will show up in their field of vision and appear in the backlog for them since their Kanban board is filtering on only these teams.
As for the backlog that I don't want them to care about I have another team called Engineering backlog which we can pick from in our planning meetings and then change team on to send epics with their stories into the execution teams.
The problem that I faced with this was if new epics were being created by various people. We have multiple Plan teams in Jira like Marketing, Sales, Operations etc. and I don't want to have to clean up new epics all the time when the Team property is not set so I have added that field to the validation rules for when new issues are created.
However, I also would not like people in the wrong roles to assign issues directly to the Engineering team but rather put it in the Engineering Backlog team.
The way I came up with this was to create an automation rule that is being triggered when the value of the custom field for the Team in the Plan is modified.
It was a bit of a hassle to understand what the name of the custom field was because in the action for Edit issue fields I had to enter a custom JSON for doing this. I ended up using Postman to get all the properties of an issue that had the Team field set and then I could figure it out with some good error messages from Jira in the automation audit log.
This is the rule that I ended up with.
I hope that someone can be helped by this use case and I am happy to get input if there are some other cool solutions!