ALM Works

If you haven't read the first post in this series on how to track Portfolio Plans in real time with Structure, please take a moment to read it before continuing as it explains configurations that aren't explained in this post.

Now we're going to combine multiple Portfolio plans into a single overview in Structure.

There are two main approaches to achieve this:

1. Multiple Portfolio plans, one Structure
   (a single structure with automation for every Portfolio plan)
2. Multiple Portfolio plans, multiple Structures
   (a separate structure for each Portfolio plan and an additional structure to combine them)

The end result in both approaches is essentially the same (we'll have a structure containing multiple Portfolio plans) but with some practical differences that I'll discuss at the end of this post.

First we'll look at putting all the plans together using just one structure.

1. Multiple Portfolio Plans, One Structure

We begin with an empty structure and create folders to contain each of our Portfolio plans:

One folder for each Portfolio plan

In each folder we add appropriate Inserters to pull in Epics from the corresponding plan (matching the plan's issue sources, as per the previous post):

Much as we did in the previous post, just remember to put the right Inserters in the right folders

At the root level of the structure* (directly under the root element) we add the following automation rows:

• Group by Parent Issue specifying 'Next level' in the Group on level: option - this will group Epics at the next level according to their parent issues from Portfolio
• Add issues belonging to epics - this puts Stories under Epics
• Add sub-tasks - this puts Sub-tasks under Stories

The top part of your structure will now look something like this:

Note how the automation rows are at the topmost level

Assuming all our plans follow the pattern of Parent Issue > Epic > Story > Sub-task then it's sufficient to add these automation rows just once at root level. There is no need to limit the scope of the Story and Sub-task extenders.

Now we have our multiple Portfolio plans inside a single structure, and we can track aggregate progress (and other values) across all of them side-by-side:

All our plans side-by-side

If we need to get a list of all the issues in any of our Portfolio plans we can now do so easily using Structure's S-JQL for Folders, which can be used anywhere that JQL queries are accepted (including other structures).

2. Multiple Portfolio Plans, Multiple Structures

In this approach we create a separate structure for each Portfolio plan, following the same procedure for each one as described in the previous post.

Next we create a structure that will combine them all and, as in the first step of the method described above, we add a folder for each plan.

We add a Structure Inserter (Automation > Insert > Structure...) in each folder to pull in the structure containing the corresponding plan:

Be sure to put the right Structure in the right folder

And once again we have a full overview of all our Portfolio plans in one place:

Same plans, different method

In both approaches, Structure will be updated in real time with changes made in JIRA. Changes made in Portfolio must be pushed to JIRA before they will be reflected in Structure.

Which Approach is Better?

The first approach is more compact and is best suited to cases where all you need is a single place to track the full set of Portfolio plans contained in the structure (i.e. there is no need for anyone to track individual plans or other combinations of two or more plans).

The second approach might appear cumbersome what with the multiple structures, but it is more flexible and makes it easier to track any single plan or combination of plans (by adding them selectively to another structure). In cases where a department or division of the company has its own plans that need to be tracked separately from others, this is the way to go.

In both approaches, the inserters can be updated to match issue sources from a single place (in the multi-structure approach, the external structures can all be edited right from the master structure).

The only strong recommendation I would make is not to use both methods at once for the simple reason that it's better to have as few places as possible where issue sources need to be kept in sync.

On (Mis-)Using the Structure Root Element to Display Aggregates

In the previous post I showed how you can quickly get an overall aggregate of values (progress, time, number fields) of the whole structure simply by toggling Automation editing mode to expose the root element of the structure. That works for our multi-plan structures too.

However, I took some flak from my colleagues for 'misrepresenting' this behaviour as a feature. So to set the record straight: It's not a feature, it's a quirk. It just happens to be a really useful quirk.

Next up: Portfolio Plans in Confluence.

^*Configuration and behaviour of automation rows: Automation rules are applied from root level to branch level, so the extenders that we added at root level are applied to everything in the structure (including the folders and their contents), while the inserters we added to the folders only act inside those folders. Similarly, the grouper is applied to everything on the level we specified. That's why we don't need to add the grouper and extenders to every folder.