In this article I am not going to explain what the Scale Agile Framework (SAFe) is and what Jira is. I assume you know, and if you need more information go to http://www.scaledagileframework.com and http://www.atlassian.com.

But before we start, there are a few things that are important to know:

• Jira is not designed for agile development. In essence it is an issue tracking tool. You need plugins to added support for Scrum/Kanban. Currently, there is no plugin for SAFe support.
• SAFe is not a prescriptive process model. It is a framework. You can implement it anyway you like, leaving out what does not work for you and adding thing that you need.

My experience with SAFe and Jira is based on the implementation of SAFe (with Jira) with a customer I worked with in a development and innovation organization of a large, multinational technology company for commercial products for consumer and professional markets. It concerned development of software (embedded and applications), hardware (controlled by the embedded software) and other disciplines (e.g. mechanics, optics). In this article, I will try to guide your through our thought process so that you might understand why we made our choice.

Implementing the 3-layered model of SAFe

SAFe (v3.0) defines a model with 3 layers:

1. Portfolio layer – for managing the business epics
2. Program layer – for managing the release trains
3. Team layer – for managing and executing the development activities

For us this was confusing. Teams exist at all levels, so we renamed “team” level to “product” level. This may suggest that teams directly deliver commercial products to the market like an ordinary Scrum team, which some teams actually do. However, all teams deliver to system integration to build integrated systems for the agile release trains (ARTs).  Therefore, we renamed “program” level to “system” level. And finally, we call “portfolio” level “business” level, although we also use the term “portfolio”.

So we have the 3 layers:

1. Business level – for managing the business epics and architectural epics
2. System level – for managing the release trains
3. Product level – for managing and executing the development activities

On each level we have a backlog as SAFe defines: portfolio backlog, system backlog and product backlog. Each backlog has backlog items. SAFe defines 3 types of backlog items:

1. Epics – on portfolio level
2. Features – on program level
3. Stories – on team level

In later parts of the article, I will extend these backlog items types for defect management.

To get agile support in Jira, you need the Agile plugin. This plugin support Scrum and Kanban boards, and several reporting extensions such as burndown charts. Scrum defines a “product backlog” which nicely corresponds with the product backlog we defined at team/product level. The Scrum board (in plan mode) has epics and stories (and potentially other issue types). Stories (and other issue types on the Scrum board) can be linked to the epics, and these links nicely show up on the Scrum board as colored links.

However:

• Jira Scrum boards do not support features according to SAFe
• Epics on the Jira Scrum boards are not corresponding with business epics according to SAFe

The development teams were already used to epics and stories on team level in their product backlogs according to the Scrum approach with Jira. According to SAFe, multiple teams (on team level) may be working on the same epics and features (on program and portfolio level). So we had to find a solution for implementing business epics and features. We saw a number of alternative solutions:

1. Define extra issue types on portfolio level (e.g. Themes), put epics on program level and stories on team level (see Sander Brienen [2013]),
2. Define a project for the business epics with a Kanban board on portfolio level, and projects for the Scrum teams on team level (see Agile plugin documentation).
3. Define a project with a Kanban board on portfolio level, a project with a Kanban board at program/system level and projects for Scrum teams on team/product level (see Agile plugin documentation).

We chose for solution #3 because it allows us to use the same approach supported by the Agile plugin (e.g. the Scrum and Kanban boards) on all levels. Every level has epics and stories (and other issue types) linked to epics, every level has a backlog reflected on a Scrum or Kanban board, every level has the standard reporting capabilities, etcetera. Users don’t need to learn new ways to work with Jira when they use the backlogs of other layers or teams.

Given our translation of portfolio/program/team levels into business/system/product levels, this comprised into:

1. Business project – contains business and architectural epics (and stories) with a portfolio backlog workflow and a Kanban board
2. System project – containing system epics (and stories and other issue types, e.g. defects) with a system backlog workflow and a Kanban board
3. Product projects (short for Product development projects) – containing product epics and stories (and other issue types, e.g. defects) with a product backlog workflow and Scrum boards

Implementing relationships between backlogs

Now, within a Jira project we can use Scrum or Kanban boards to view and manage the relationship between epics and stories (and other issue type). For example, on the Scrum board in plan mode you can drop a story (or an issue of another issue type) on an epic to set the Epic link. As a result the Scrum board shows a colored link on the story, and you can do all kind of nice reports as supported by the Agile plugin.

However, we need to relate the product epics (on the product backlog)  with the system epics, and the system epics (on the system/program backlog) with the business epics or architectural epics (on the portfolio backlog). We do this with an “implement” link, which is a bidirectional link (“is implemented by” / “implements”). (See also Sander Brienen [2013]).

So we use 2 link types:

1. Epic link – for agile relationships within a Scrum team
2. Issue link of link type “implement” – for backlog relationships across SAFe layers

The Epic link relationships can be viewed and managed through the Scrum boards provided by the Agile plugin. But Scrum boards cannot visualize or manage issue links. For that you need to open the issue and view/manage the issue links in the issue itself. For example, when you open an epic you see a block with “Issue Links”  and a block with “Issues in Epic”. But to visualize and potentially manage the relationship of product stories linked to a product epic, linked to a system epic, linked to a business epic, you need the Structure plugin. The Structure plugin is a powerful plugin, but also a nasty beast. I will tell you about it another time.

Conclusion

Having backlogs and backlog relationships in Jira in place is only the beginning of the implementation of SAFe with Jira, but it is an important foundation. One of the challenges is of course how to work with the information and with Jira to make the release trains and the development teams effective. There is a lot more to tell, but I’ll have to wait until part 2.

#author-avatar

#author-description