How To Create A Feature In Jira

Transitioning to the Scaled Agile Framework (SAFe) immediately begs the question: Which hierarchy should we choose? If you're a brand-new organization, congratulations, you can make whatever choice suits you. If you have legacy data to worry about, things get complicated. Read this to figure out which move makes the most sense for you.

Learn how to limit disruption to your business

In the Scaled Agile Framework (SAFe), epics are broken down into features, which are then broken down further into stories. Alternatively, Jira natively comes with a very useful epic link between stories and epics, and many entities (including Atlassian) incorporate a layer above the Jira epic called an initiative.

This means choosing between Atlassian's initiative-epic-story approach versus the SAFe purist epic-feature-story. While the distinction may seem trivial at first glance, there are some far-reaching implications that should be considered before choosing which option is right for your organization.

Further complicating matters, there are multiple ways you can adopt the epic-feature-story hierarchy in Jira. For the sake of this article, we're going to look at the two most popular methods. The first is by renaming Jira's epic to a feature (which can be done with a handy app) and then creating a new issue type called epic to add above the feature. The second method involves ignoring the built-in epic-story functionality, creating regular issue links between an epic and a new issue type called a feature, and using the same issue link to connect features to their stories. We will refer to these methods as the epic-renaming and epic-relinking approaches, respectively.

So, which is right for your organization? Each choice has its advantages and disadvantages. Your task is to determine which solution offers the most benefit and least liability for your teams. While many factors will go into this decision, we're going to focus on the three primary factors that should always be considered.

Alignment

You might prioritize being in alignment — that is, sharing the same vocabulary — with the Scaled Agile literature and all the classes your team will follow to learn about SAFe. It will also help to be able to easily reference the Scaled Agile epic-feature-story hierarchy when discussing SAFe with friends, connections, conference attendees, and most importantly, your colleagues.

Unfortunately, there is no easy solution to this. Renaming the epics for all Scaled Agile teams' documentation and being mindful of how to properly read them costs extra effort — because of that, the Atlassian community is starting to standardize around the Jira native approach.

Legacy

The second consideration is legacy. If your Jira instance is new, you don't have any legacy issues you need to preserve. But if your Scaled Agile transformation is happening gradually, and you have several years' worth of information in your Jira instance, changing the meaning of an epic or creating a new layer between epics and stories can have consequences for your tooling going forward, for teams that have not yet gone to the SAFe model, and for any auditing that may happen down the line.

The epic-relinking approach is the best for preserving legacy data, but there is a sacrifice in Jira functionality that accompanies this. Namely, it further limits Jira's hierarchical visualization by preventing team members from seeing the roll-up/break-down of the epics and stories on their Jira boards.

Functionality

Similar to concerns about impacts to historical data, changing your hierarchy can impact other teams — without careful planning, collateral damage to unrelated teams can create obstacles.

Companies that are part of an agile transformation often gradually work their way to either Essential SAFe or another SAFe configuration. This means not all teams will move at once, and as teams do become part of agile release trains (ARTs), it's imperative to preserve as much of their current way of doing things as possible.

This creates a conundrum for companies: Which method is least disruptive to all teams? If you are gradually onboarding teams, for example, epic-relinking does not impact teams until they are onboarded to SAFe, whereas changing epics to features requires non-SAFe teams to adjust right away (which may be a good thing for consistency). In making this decision, it's important to ask who will have to change the way they work, and whether this disruption is worthwhile or not.

It should be noted that Structure for Jira is useful regardless of which path you take, as Structure is flexible and can work within either hierarchical overview. They also support all teams, regardless of whether they are on the ART or not.

Key takeaways

We can't tell you which method is best — too much depends on your company's situation and your plans for the SAFe transformation. But a few main ideas can help you figure out which path to take:

Initiative-Epic-Story (the native Jira hierarchy)

Pro: Requires no effort to rename or relink; is popular among the Atlassian community
Con: Puts you out of step with the Scaled Agile community

Epic-renaming (renaming epic to feature and creating a new issue type, called epic, to be above the new feature)

Pro: Preserves Jira functionality better than epic-relinking
Con: Can be disruptive to non-SAFe teams

Epic-relinking (creating issue types between an epic and a story)

Pros: Preserves legacy data better than renaming; does not impact non-SAFe teams until they are onboarded
Con: Sacrifices some Jira functionality

Whichever approach you end up taking, it is good to be aware of the downstream impacts to the rest of your organization. If you know of any other considerations here or have comments/questions about this article, please reach out to us at either safe@almworks or solutions@almworks.com.

Future articles in this series tackle Program Increment planning practices, including how to track your planning within Jira. Be sure to check out almworks.com/safe for updates and more information.