Introduction

Jira is a very robust tool for Task management and more. Often enterprises start using Jira to address quite simple needs, like monitoring task status, and with time start using more advanced features that cover a growing number of enterprise processes.

Often Jira itself ceases to be sufficient. Fortunately, Apps available on the Atlassian marketplace can fill any missing features.
Some of the most known Apps that are meant to expand Jira with Portfolio and Project management functionalities are BigPicture and Structure (or, to be more precise: Structure, Structure.Gantt, and Structure Cross Team PI Planner – three Apps that work together. We will refer to these three as simply “Structure”).

Due to the length of this text, it will be split into three articles.

• In the first article, we will cover the topic of creating task hierarchies in both apps.
• The second article will cover elements related to waterfall project management.
• Third, and last, the article will cover the Agile approach and summary.

Comparison approach

In this article, we will discuss how to build a hierarchy in both BigPicture and Structure – Portfolio level, Project level, and sub-project level – and what information is available on each of these.

On the Project level, we will focus on discussing three approaches to Project Management, and how to work with scheduling/creating timelines and planning resources in each of them:

1. Waterfall – where work schedule, resources, etc. are planned upfront.
2. Agile – where work is performed in iterations, and work is planned for upcoming iterations.
3. Hybrid – where a high-level plan is created upfront, but more detailed plans are developed similarly to Agile Approaches.

Building hierarchy

Both BigPicture and Structure allow building multiple-level hierarchies to represent different levels of work, e.g. Projects, phases, tasks, and sub-tasks (or Product Increments, Iterations in the Agile Approach). Also, Projects can be grouped into higher-level entities, like Programs and Portfolios.

BigPicture uses so-called “Boxes”, as the main configuration element. In Structure, the main element is called “Structure”. Both of these can contain in their scope a user-defined data set which can be presented as a hierarchy built manually or automatically.

On top of that, Both Apps allow the creation of nested objects. BigPictures Boxes can be nested one within another, so one Box can represent e.g. Project Portfolio, while lower-level boxes will represent individual projects within the portfolio. In Structure, on the other hand, Structures cannot be nested within one another, but folders can be put into the structure. Each folder may have a different configuration and scope, resulting in a similar outcome with Structure representing Project Portfolio, and folders representing projects.

 

 

 

 

Manual Hierarchy

Creating hierarchy manually is the simplest way to determine parent-child relations between multiple Jira issues. It is available in both BigPicture and Structure with very little difference. Manual hierarchy is flexible but requires defining parent for each Jira issue. It means that for each new issue that appears in scope, additional action of placing it in the hierarchy will be required.

 

Automatic Hierarchy

A more advanced way of creating hierarchies is doing so based on automatic rules. It is a more complex approach, but it is less prone to user mistakes, and usually has to be done only once in a while (not even for each Box or Structure, as both of these can share configuration with other Boxes/Structures, therefore automatic hierarchies can be defined once, and be reused).
Automatic rules for hierarchy creation are where the first differences between BigPicture and Structure are.

In Structure, hierarchy is built based on issues that are already in the scope of this structure, but additional issues can be pulled into the structure based on the Generator called “Extend”. There are several different types of Generators, that allow the building of a hierarchy based on e.g.:

1. Links between issues – This allows for building a hierarchy based on Jira links that exist between issues. The direction of said links is relevant but can be set when defining a Generator. This option allows building hierarchies with any depth, but it requires connecting all relevant issues with links.
2. Contents of Epic – Issues in the Epic are put as children of this Epic. It is a very good solution for teams that already use Epics for other purposes. With that, the structure can be built with little additional overhead.
3. Sub-tasks – All Sub-tasks are put as children of the main task.

What is important (and different than in BigPicture) is that one issue can be displayed in multiple places in the Hierarchy – e.g. if there are two generators: Epic-based and link-based, that would suggest two different parents for the given issue – this issue will appear under both of them. This issue will be marked as one that is displayed multiple times.

In BigPicture hierarchy is built by structure builders. Initially, they may seem similar to ones in Structure, as they allow to define parent-child relationships based on things as:

1. Project
2. Epic
3. Sub-task
4. Jira Link
   But also:
5. Component
6. Sprint

Two major differences between BigPicture and Structure are:

1. BigPicture builds a hierarchy based only on issues that are within the scope of the box. Structure builders do not add additional issues to the scope of the box.
2. One issue cannot be displayed twice in structure. If there will be two different structure builders that would put the issue under two separate parents – only one of these will be applied (one with a higher priority set by the user). In general, this situation should be avoided and may be confusing when initially configuring the box. Fortunately, our experience shows that users do not have a problem with that, as it is usually set once and that’s all it takes.

Another major difference is that Structure can use the Grouping feature to create hierarchy. In that case all issues with the same value by which we group, will be gathered under the same element. Interesting thing is, that if these issues will have some child elements, they will be moved under grouping, even if they will not have value by which we group. It may not seem clear, but an example will help.

Let’s say we have the following Structure created by Extend Generator: 

-> Epic (Fix Version)

           -> Story (no Fix Version)

                    -> Sub-task (no Fix Version)

We store Fix Version information on the Epic level (and not on Story or sub-task level). If we will group Epics based on Fix Version, the hierarchy will be:

->Fix Version

         -> Epic (Fix Version)

                 -> Story (no Fix Version)

                           -> Sub-task (no Fix Version) 

So lower level hierarchy will be kept, and Stories and Sub-tasks will be indirectly grouped by Fix Version, despite the fact, that they do not have this information. It will be done based on Parent (Epic) Fix version. 

This feature allows using the grouping feature in a bit easier way, as users do not have to maintain grouping information on all grouped issues and is often very helpful in situations where Structure is introduced on top of a mature Jira project with a lot of data allowing to avoid update of thousands of issues with certain information used to build the structure.

BigPicture, on the other side, approaches grouping in a bit different way. First of all, it is not used in hierarchy builders, but in a way, to create an alternative view of issues – when grouping is applied, hierarchy is visually (and only visually, as it still exists in the background) replaced by groupings. You can create multi-level groupings which, in turn, will create an alternative hierarchy.

It must be said, that when the grouping feature is used, some of the features that require hierarchy to function are disabled.

The second difference between BigPicture and Structure is that Groupings in BigPicture ignore hierarchy. If the issue does not have a certain value (e.g. Fix Version), it will not be grouped, even if the parent of this issue has this value assigned.

Boxes Structure

BigPicture has additional features that allow having the structure of Boxes. In short, it means that there can be one configuration of the Box, that represents Project Portfolio, that will contain Boxes that represent Project, which in turn will contain other Boxes for Phases or Iterations. 

Thanks to that, we may have Boxes representing projects (and their whole content) nested within Box that represent Project Portfolio or Program. These Boxes may have different settings in areas like information displayed, permissions, etc.

Structure, on the other hand, does not have that kind of functionality. Therefore, if we want to set up a Project Portfolio, we need to create a separate Structure that would contain all projects in this portfolio. That means, that scope of each project will have to be defined twice (in Project Structure – e.g. Project Managers, and in Portfolio Structure – for. e.g. Portfolio Managers). Each change in data scope will have to be performed in two places – otherwise, discrepancies will appear.

Summary

That is it when it comes to issue hierarchy in both of these apps.
The next article will cover features supporting Waterfall project management!

Have any questions? Contact us!

If you would like to learn more about BigPicture, talk about the best way of using the tool available in your company, talk about possible training or implementation help, and remember that in Genius Gecko we are the experts in this area. We are working with BigPicture almost from the beginning and we are probably the most experienced people in the world currently when it comes to BigPicture project management. We might also add, that we are not the most expensive! ?
Don’t hesitate to reach out to us for a free first session during which we will help you get the most out of this amazing Project Management tool.

See also:

Genius Gecko YouTube Channel

Training courses (LIVE and online)