By Robert Leitch on February 10, 2017
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:
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.
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:
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).
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.
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.
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.
Hierarchical issues for great project management in Jira
Jira ClientDesktop client for Jira