Implementing SAFe with Jira (part 2)

This is part 2 about implementing SAFe with Jira. In part 1 I explained how we implemented the portfolio, program and team backlogs as the 3-layered structure of SAFe in Jira. You may recall that we renamed them to business, system and product levels. In part 2 we will dig more deeply in connecting the layers.

Structure plugin

Since Jira (core) is not able to visualize linked relationships, we use the Structure plugin from ALMworks. On a structure board, you can add Jira issues, you can sort them and put them in a hierarchy (i.e. an issue nested under its parent issue), manually by drag-and-drop or automatically by synchronizers. A synchronizer interprets the data in Jira (e.g. a filter, Epic link or issue links) and puts the issues in the structure at the right place. Synchronizers work bi-directional. For example, by adding or removing a link the synchronizer places the issue on the right place in the structure, and by changing the place of an issue in the structure, the synchronizers adds or removes links in Jira.

So if we have a business epic -> system epic -> product epic -> product story -> subtask relationship (through Epic links and Issue links of the “Implement” link type), the Structure board visualizes the hierarchy structure as nested issues. By adding the columns on the Structure board (through views), you can see, check and even change the value of a Jira issue. For example, when a release on team level is later than the release on program level, you can easily see this by looking at the FixVersion/s column.

One of the features of the structure plugin is its time tracking capabilities. The plugin is able to aggregate the planned and actual effort (original estimate, remaining estimate, logged work) over items in a structure. For example, if an epic contains 4 stories each estimated at 3 days work, and the epic itself requires an extra 1 day work, the estimate of the epic is 13 days work (4 * 3 days + 1 day).

There is a lot more to say about using the structure plugin and its synchronizers. I may come to that later.

Agile Release Trains (ARTs), Program Increments and Sprints

An Agile Release Train (ART) is planned and organized in iterations called Program Increments (PIs). We define 2 PIs per year, corresponding with the commercial windows of product marketing to the market. In fact, we don’t even use the term “Program Increment” and call them “windows”. Each PI (window) consists of 3 releases, and each release consists of 4 sprints. In Jira, PIs (windows) and releases are defined in the FixVersion field and sprints are defined in the Sprint field.

  • Business backlog items are planned in windows: W1/2015, W2/2015, W1/2016, …
  • System backlog items are planned in releases: 1.1, 1.2, 1.3, 1.4, …
  • Product backlog items are planned in releases (1.1, 1.2, …) and assigned to sprints

As you can see development and releasing are both on cadence. SAFe says “develop in cadence, release on demand”, but since we come from a traditional stage-gating world, releasing in cadence is a old habit. We may change that in the future.

Portfolio/business level and program/system level have no sprints; they use Kanban, which represents a continuous flow of input (new items) and output (closed items). On team/product level we do use sprints with Scrum. Typically, sprints are 2 week time-boxes. The name or numbering of each sprint is dependent on the team; sprint 6 for one team may not coincide with sprint 6 of another team. But by using separate projects in Jira for portfolio, system and for each product team, each project may have their own set of version values and sprints in Jira. This requires some alignment between system and product level, because we want the release numbers to be the same for all projects, at least for now.

Of course, our world is not ideal. We have teams with a different iteration lengths and we even have teams that do not even follow Scrum, e.g. hardware development. That is okay as long as they are able to deliver for and integrate with the release.

The Structure board shows the hierarchical relationships from portfolio to system to product level. The fixversion column shows the windows and releases and the sprint column shows the sprints, so we can spot inconsistencies easily. The estimated effort column shows the aggregated effort and the story points column shows the aggregated story points. This helps us decide about the release content. And the progress bar shows the aggregated progress of a portfolio item and all its descendants. That way, we can visually check the consistency and progress.

Agile release train (ART) planning

Before a release starts, we have an ART planning session, which we call the “release train workshop”. The portfolio backlog in Jira containing the  business epics on the strategic roadmap for the coming years, specifies the business epics for the coming window. Since we have 4 releases per window, we don’t need to do everything in a single release. But the question is: how much can we do in this release?

The first step is to divide the portfolio items (epics in the Portfolio project in Jira) into multiple system items (epics in the System project in Jira). Typical system epics are a minimum viable product (MVP) of the business epic and successive increments.

After putting them in Jira, they need to be estimated: how much capacity does it require from each of the teams for each of the system epics? In Jira, you only have one estimate field per epic, so that is insufficient to capture the individual estimates of each team. So instead of trying to extend the system epics with extra custom fields, we make epics in the Jira projects for the product teams and link the product epics to the system epic with an “implement” issue link. Through the structure plugin, the product epics show up underneath the system epics and the estimate column (or story point column) shows the aggregated effort (or size) of the product epics for the system epic.

Unfortunately, Jira (or better, the structure plugin) does not allow us to extract the aggregated data to reports or even to queries.

Having these estimates brings us to the next question: will it fit the release? Accumulating the estimates of the system epics for the release may give the impression that the total capacity of the teams is able to cope with the total amount of work for the release. But fortunately, it is not a realistic approach either. If one team is overloaded, the release cannot be completed in time anyway. So a better metric would be to look at the total estimate for each team for the release. And since the estimates for a team are all in the same Jira project, it is easy to create a report that shows the totals.

Knowing the total estimate per team allows us to decide whether the release content fits. Of course, we are running into the situation that it does not fit! In those cases, the MVP definitions may even be reduced further and the estimates need to be redone. So in practice, the information is not actually entered in Jira until there is sufficient consensus about the feasibility of the release content and the estimates. Jira is not a planning tool and does not allow the dynamics of what-if scenarios; I wish.

Conclusion

In part 1 I described how we have implemented the 3-layered backlog structure in Jira. In this part 2 I have made the first step of making use of this structure to deal with release content and estimation. Part 3 will take us to the next step. If you have ideas what next step you would like me to focus on, feel free to let me know.

Advertisements

About Frank Schophuizen (fschop)

Hi, my name is Frank Schophuizen and I am working as a consultant in CM, Agile and ALM for TOPIC Embedded Systems. I have over 30 years experience in software development in the technology industry, with the last 15 years mainly in process improvement, deployment and integration of methods and tools in the area of CM, Agile development and ALM. I am strongly interested in the complexities of collaboration and integrations in multi-project and multi-site organizations. I have worked with various technology companies such as Philips, ASML, NXP and Vanderlande, and with various tool vendors such as IBM Rational (e.g. ClearCase, Synergy, Jazz products) as well as open source tools (e.g. SVN, Git, Jenkins, Trac, Eclipse). I am living in Eindhoven, the Netherlands, with my wife. We have 3 adult children. My main hobbies are classical music and photography.
This entry was posted in agile, complex systems, large projects, project management, systems, tools and tagged , , . Bookmark the permalink.

11 Responses to Implementing SAFe with Jira (part 2)

  1. Pingback: Implementing SAFe with Jira (part 1) | fschop

  2. Akbar Waseem says:

    Have you tried using JIRA Portfolio for SAFe?

    Liked by 1 person

  3. Hi Frank!
    Did you happen to investigate CPrime’s “SAFe Plugin for JIRA”? It doesn’t seem to be on Atlassian Marketplace so its not easy to find. I can find some links to it from CPrime, but not much in the way of details/documentation:
    http://www.slideshare.net/cPrime/adopting-safe-with-jira
    https://www.cprime.com/2015/04/jira-safe-the-easiest-way-to-manage-work-across-project-program-and-portfolio/
    • also http://cprimelabs.com/jira-safe/ and https://www.cprime.com/tag/jira-plugin/
    I also note that JIRA Agile places restrictions on the out-of-the-box “epic” issue-type (for example, it can’t link to other epics via the “epic link” field an you have to add another field (and/opr another issue type) if you wish to distinguish between different types of epics (e.g., product/project-level versus system/program-level, or architecture versus business versus development or deployment)

    Like

    • The restriction that epics cannot link to epics through an Epic link is indeed an issues we encounter. I may not have elaborated on that in my blog, but in practice we use the Structure plugin with synchronizers to visualize both epic links and issue links.

      Thanks for letting me know about the “SAFe with Jira” plugin by cPrime.

      Like

  4. Pingback: Implementing SAFe with Jira (part 3) | fschop

  5. Shelley Staten says:

    I would like to know how you manage in releases. Since Jira does not allow you to share fixversions across projects how do you assemble/provide visibility into stories and features that are candidates for a release and approve them for release and managing the workflow to prepare them for release (i.e. regression, UAT, marketing communication, etc.)

    Like

    • Things have evolved a bit in the last year since the previous posts on this subject. For Starters, there is a new plugin called “BigPicture: that claims to be SAFe “compliant” (although I think it is SAFe 3.0, and not yet 4.0).

      Also, JIRA Portfolio (from Atlassian), when added to JIRA Software, has things called Portfolios and Programs that are separate from JIRA Projects and versions. And It is very common to sometimes see a “program” uses to represent a “release” (depending upon your usage of t he term “release”).

      It is also not uncommon to see folks add a custom field called Release (possibly even Affects Release/s) and to use the same set of Contextual values for the Release field apply to multiple projects.

      Like

    • Great question, not so easily answered. You can’t share fixversions, but you can use the same fixversion in multiple projects. Using a structure board (Structure plugin) you can visually inspect fixversion values of issues nested under a business epic or system epic. Jira does not know which fixversions “belong together”, but you should know. If Jira would be able to show fixversions on a timeline for issues that are linked under a higher level epic (can Portfolio plugin do that?) it would be easier to inspect fixversions.
      Concerning approvals and release preparation it cannot be done with Jira. It is not a planning tool and it does not support what-if scenarios. However, with Structure v3 you could group issues in folders and check the accumulated estimates (in story points or hours) comes out.

      Like

  6. Reblogged this on .

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s