Building a SAFe Issue Type Taxonomy

When undergoing a SAFe transformation, many organizations start with the familiar. This may include adapting tools currently in use, such as Jira. Jira is flexible to take on the changes from SAFe, but does require some additions. Let's take a look at what changes we need to make to issue types in Jira to model the Scaled Agile Framework.

Start with the Essentials

Most SAFe transformations begin with the Essential SAFe configuration. In this configuration, cross-functional, self-managed Agile teams are grouped together to form an Agile Release Train (ART). Often, these Agile teams are already using Jira, setting up their work in a Scrum or Kanban project.

Let's start with the default issue types seen in typical Jira Software projects:

On the whole, these can be used as-is by the agile teams for day-to-day work. The real issue type that is somewhat out of alignment with the SAFe methodology is the Epic. SAFe uses Features to outline committed work within a Program Increment, or PI, which is a grouping of five sprints that outline an Agile Release Train's "timebox".  Because it's a container for smaller pieces of work, the Epic is an ideal issue type to encapsulate the work meant for a PI.  Often the Release Train Engineers and Program Management, key players in the Agile Release Train, may make a request to the Jira Administrator to change the Epic issue type name to Feature to match the SAFe taxonomy. But changing the naming of the Epic issue type breaks the core functionality of that issue type.

Workarounds to this problem include mentally thinking "Feature" every time you look at Epics in Jira. This solution causes confusion among Jira users adopting SAFe and slows down adoption of the tool and ultimately the process.  Another alternative may be to create a custom "SAFe Feature" issue type, which may be clunky because it won't have the container-like capabilities that a Jira Epic will have. If you want to use the advantages of an Epic in Jira and have it named "Feature" to keep the SAFe taxonomy, an easier solution is installing the SAFe Feature to Epic Translator for Jira app. This app allows the Jira administrator to rename the Epic issue type to Feature easily, and have the name changes propagate throughout Jira.

With the naming conundrum out of the way, you can add custom fields for WSJF.

Enabling Enablers

Although an Agile Release Train starts with intentional architecture, the ART continues to discover design and architectural elements that require planning and execution so that dependent Features can realize value. In SAFe, these are shown as Enablers, which form the basis of an Architectural Runway.

Because Enablers are seen at all levels of the framework, the work can manifest itself as several issue types. We cannot clone our Epic-turned-Feature issue type so let's capture our intent with a custom field called Feature Type.

You can then discern the different types of Features by setting up Card Colors on your board based on a JQL filter.

At the Story level, you can create a custom field (Enabler Type)  or create an Enabler issue type for each category of Enabler. Card color choices on the Boards can be by issue type or by JQL filter. Because we recommend having as few issue types as necessary, we prefer setting up the Enabler Type custom field, where creating specific Enabler issue types are only necessary if they follow a different workflow.

Building Capabilities

For some products, one Agile Release Train is not enough. In this case, ARTs are grouped to Solution Trains to provide value. The Solution Train may work on something for a single PI that multiple ART's have a part in working as Features. The container for the Features is called a Capability for the Solution Train.

We can think of a Capability as a container for Features. The easiest approach for this is to create a Capability issue type that can link to our Epic-turned-Feature issue type. This solution is best accomplished using Portfolio for Jira.

SAFe Epics

Epics in SAFe carry a broader context. Often, these capture business initiatives that can be broken down to Minimum Viable Products (MVP) that are captured as Features for an ART to design, implement, and deploy.

Epics are owned by the business stakeholders and can be kept at a SAFe Portfolio project in Jira. They can be a custom issue type with the four necessary custom fields

• Value statement - A description of the epic.  It usually follows this formula:
  • For <customers>
  • Who <do something>
  • The <solution>
  • Is a <how>
  • That <identify value here>
  • Unlike <current solution, competitor's product, or no solution>
  • Our solution <why>
• Benefit Hypotheses - the quantitative and qualitative benefits the business may see if the hypothesis or hypotheses are correct
• Leading Indicators - any early measures that can predict the business outcomes
• NFRs - Any Non-functional requirements

These can be parents of Features or Capabilities (if running the Large-Solution configuration of SAFe) and maintained using Portfolio for Jira.