A Super simple SAFe Setup in JIRA

4 min readMay 23, 2018

For the last year or so I have been working with a few different clients that all aspire to Work in a scaled agile way. All of them has been having a JIRA Here is a description of a setup that two clients run. One of them as an essential SAFe setup and one as a 3 Level SAFe with 4 ART:s and a large solution

Lets look at what you need from a tool to run SAFe

We need to be able to identify (dimensions)

Everything a Team/ART/Solution/Portfolio works with
Which Team/ART/Solution/Portfolio that is lead for a deliverable/issue
Which Initiative a deliverable/issue is related to
Planned delivery for a deliverable/issue (Iteration and PI)
Backlog items for refinement
Which level a deliverable le is part of
Planned and agreed dependencies between deliverables/issues for Team/ART/Solutions
Which type a deliverable/issue has
Which status a deliverable/issue has

Design Guidelines

Maximize the usage of the strong features of a tool
Maximize flexibility
Minimize complexity
(e.g. number of issue-types)
Should be easy to make ad-hoc searches for specific scope
(comnbinations of dimensions and tool requirements)

Each Planned Issue in JIRA

connected to a team
connected to a program
planned to be delivered in an iteration

Could be

related to an initiative (SAFe epic)
Enabler vs Business
Stretch — To mark issues part of a stretch objective
AtRisk — To mark issues that might not be delivered according to plan
For initiatives: Portfolio, Solution or Program attribute

JIRA Issue structure

Looking at the Standard Jira Issue hierarchy model there is three types of Issues

Epics: A parent issue type that a lot of plannings support for the teams is built around. The epic issue type can not be renamed and no other issue type does have this support

Issues: A generic Issue type that can be connected as a child to an epic or not

SubIssue: Issuetype that is connected as a child to an issue

Design decisions for Dimensions

SAFe Epic !=JIRA Epic. Looking at the strength of the tool it really is the relation and support for the Epic/Issue relation so this we should use to its full capacity. This means that the JIRA Epic can not be reserved for SAFe Epics as this would remove many usefull features in the tool on the team level. I would go as far as saying that if you can not live with the fact that the SAFe epic do not map to the JIRA Epic You really should get yourself another tool

Features and Capabilities In our case we use JIRA Epics as both SAFe Features and SAFEe Capabilities. A JIRA epic that needs contributions from more than one ART is a Capability. We see no added value making any other distinction between these two artefact types. All work needed to deliver the Feature/Capability is connected to the JIRA Epic this way we can see the dependencies between teams

SAFe Epics JIRA is not Strong on Hierarchies (Portfolio and other Plugins do not change this) as a result of this SAFe epics are not represented with a root issue and links instead The parent SAFe Epic needs to be represented on each issue to make it easy to find the whole scope via JQL queries.

Team The team dimension we handle by the Service Area custom field. From the SAFe perspective we do not care about the JIRA project dimension as JIRA projects really stands in the way of collaborative work cross teams. Ideally we would do all work in one JIRA Project. The team that takes lead on a Feature/Capability is the team that the JIRA Epic is assigned to.

ART What ART is delivering a Feature/Capability/Story needs to be represented on all planned issues to make it easy to find with JQL.

PI/Iteration in order to not mess with Jiras Sprint concept and let all teams create individual sprints but still be able to find issues based on when they are planned we need to repressent planned delivery PI/Iteration on all planned Issues

How to represent dimensions?

In order to keep it simple and flexible (And because we are not alone on the JIRA instance) we have chosen to use labels. In order to make this manageable we created a labeling standard with prefixed labels.

# for Epics (#EpicName)
$ for PI.Iteration for planned issues( $PI3.1) for roadmap ( $PI4)
+ for ART (+ArtName)
Other dimensions are represented in standard JIRA config

You get the drift. in general we try to come up with short labels like the IssueKey prefix in JIRA projects. In order to highlight these label types we have created custom CSS that give them different colours. A nice thing with labels is that they can be added quickly as there is only one field and the fact that the L short-key enables label editing in both Boards and JQL search results. We use bulk updating of issues heavily to apply the correct labels to issues. We have also built a simple tool for generating queries to find all children to JIRA Epics in the result of a JQL query to make this work easier.

Boards

ART/Large Solution on this level we have 2 boards 1 kanban board with only one column that we use for prioritisation and one ordinary kanban board to aggregate all plans. Both of these boards are equipped with a lot of different quick filters for different dimensions so that we easily can make whatever slice we would want to look at. We have also created custom css to highlight what dimension they represent. The Board base filter is a query selecting all issues that have an ART label.