Make relevant Features visible on your Jira board

[#1]

This writeup is aimed at automating and simplifying a use-case around features(Jira Epics) and Jira boards especially encountered when integrating Jira with Jira Align.

Background

When integrating Jira with Align for a large Organisation the common Jira landscape which exists is the following i.e. a single Jira project shared by multiple teams wherein each Team is having its own board.

Each Team board is built on an issue filter which uses a custom field (Team selector) for the selection of the relevant team.

Let's suppose we have 4 Teams named after the above major cities and based on the selection of value in the team field the story will appear in the backlog of the relevant Team board.

This approach works well and is also quite scalable because each Team has its own backlog on its own board and the Jira custom fields supports different contexts as well i.e. different set of values for different set of projects.

Problem Statement

If you see the definition of a Feature (Jira Epic) from the SAFe website, it’s the following

A Feature represents solution functionality that delivers business value, fulfills a stakeholder need, and is sized to be delivered by an Agile Release Train within a PI.

And this sounds great, but often we see a pattern that a feature might be too technical or not defined at the right level i.e. not being solution or business focussed or even just being used as an entity to group stories. And this common pattern leads to the scenario wherein instead of having an ART (program) working on 10-15 well-defined features in the PI we end up with at times over 50 features.

And this is when you see the team boards in Jira getting inundated with the Features (Jira Epics) on the Epic panel. In the following screenshot, you can see that there are 5 Features on the Epics panel of the Scrum board of the “Amsterdam” team.

The Amsterdam team might not be working on all of them yet they see all of them in their Epic Panel. Now, imagine seeing a list of 50 features on this list for the PI and most of them might not be relevant for this team. This just creates a cumbersome situation for the stakeholders to navigate the team board and they are only interested in features which they are contributing towards.

Solution that scales

A simple yet effective solution to this will be to add a tag/label on the features which are contributed by the relevant teams. So in this case, let's add a label called “Amsterdam” to the first 3 features of the project as only these 3 features are relevant for the Amsterdam team.

And this is how the Epic Panel now looks

Thus, we now see only the features which are relevant to the team instead of the complete list which can be even up to 50 during the PI planning & execution.

And the following is the board filter query which I used to fetch me only the relevant Features/Jira Epics and all the stories which the Amsterdam team is working on.

project IN ("<Project-Name>") and ((type in (Epic) and labels = Amsterdam) or "Team selector[Dropdown]"=Amsterdam)

Now this solution works well but unfortunately is not very scalable due to the need for manual intervention because there is a high possibility that we might miss adding labels to features in a large and complex setup with multiple programs and hundreds of teams.

Hence to address this issue, we will now look at the Automation rule which adds or removed the relevant team labels on the Features/Jira epics when child stories are updated with team selection.

This part of the automation rule is triggered when the “team selector” field has a change and the value is non-empty.

Scenario -1

The “Team selector” value on a story changes from “London” to “Amsterdam”, now in this case, we will add the new label value on the parent Epic i.e. Update label

Here I am fetching the new team value from the story which is coming from the custom field Team selector (id 12954) which in this case is Amsterdam and adding that as a label on the Epic.

Since the former value on the team selector for this story was London hence I will now check if Epic has any other child stories for the London team and if not, remove the label London from Epic. So that this Epic is no longer visible on the London team board as it doesn’t have any child stories for that team.

Following is the screenshot from the above automation rule, and an expansion of “Check for child stories for original team value”

Here the smart expression “{{fieldChange.fromString}}” provides the former value of the team field (cf[12954]) on the story which in this case is “London” and if there are no child stories in this Epic for team London then we move the team label from the Epic in the next step “Remove Label”

Here the label gets removed from the Epic which is basically the original value of the team selector field which triggered this automation rule. And since the label was London thus the Epic should no longer be visible on the London team board.

---

The second part of this automation is “Else” block of this rule which executes in case the Team selector field becomes empty and thus no longer holds any value. In this case, again we will remove the label from the Parent Epic just like we saw above but only after making sure that there are no other child stories belonging to that team linked to the parent Epic.

Using the above automation rule as a global automation rule you should be able to scale it across a large and complex Jira instance and the teams will only see the relevant Epics on their team boards based on the JQL board filter query which I have shared in this writeup.

And since labels also sync bidirectionally with Jira Align as tags thus the team labels on features will also be available in Align in case you want to filter by team on different views.

I have used the Automation for Jira app for the above solution and this app is bundled as part of the Jira cloud premium as well as the Jira DC offering.

Feel free to share your thoughts about this approach in the comments below.

And Special thanks to @Mathias Richter for sharing his inputs and insights around  Automation for Jira and to @Philipp Barry for the initial conversations around this topic.