Usage / Main features
Within the global app configuration, you can select a project and config it as a higher-level project controlling all the other projects you specify as lower-level ones. Also, you can easily select a new default issue type like initiative, action, or feature, representing higher-level none-epic activities for this (business) project. The app automatically creates these issue types in addition to Jira's standard-issue types. Depending on your preferred approach (top-down or bottom-up), you will get guided next steps. A higher-level project can also be controlled by another project one abstraction level above to build a multi-level project hierarchy representing your business needs.
Interactively, you can associate epics and none-epics (initiatives, activities, features, stories, tasks, etc.) to parents and/or break them down into one or multiple children within the related, controlled projects as configured. In all cases, a flexible search mechanism supports you to find fast what you are looking for. Also, you can create a related issue within a higher-level project and assign a suitable epic in a single step. Additionally, you can create an epic within a controlled project as a new child. You can do all this without leaving the current issue view: an extended breadcrumb list makes that possible on the issue view.
Having linked all your lower-level issues or broke down all your high-level initiatives, you will see a cockpit for aggregated figured of progress, costs, and benefits per issue view or per project via the menu item "agile@scale".
Suppose you enter or update estimations (story points or time tracking figures) or change the status of a lowest-level issue (leaf node of your work break-down tree). In that case, the app automatically aggregates the delta value to all higher levels in the background. So, you can use Jira's standard features for reporting like burn-down charts, etc., on all abstraction levels without manually maintaining estimations or statuses. Especially the status information is essential to indicate which issues have been done.
As soon as a leaf issue changed its status into, e.g., "in progress", the app also updates all related parent issues accordingly to overall hierarchy levels.
The app will also switch the related parent issue into "done" if all children are "done". So if you add another new issue for such an epic later, this will put the epic's status back into the previous status category if it is "done". You just have to update all leaf nodes, respective lowest-level issues. Manually editing the status of a higher-level epic will not affect others.
Below the cockpit, you can display all associated issues as a tree or just the leaf / lowest-level issues only. Also, the displayed columns can be flexible configured to show what you would like to see. Mixing team-managed projects and company-managed projects, all fields with the same name are displayed within a single column to make life easier. Jira-internally, context fields with the same name are stored within different custom fields per team-managed project. All that is unified by the app for better user convenience.
In addition to all native Jira fields (system fields, custom fields, context fields), the app also supports traffic-light fields, which are often used to illustrate a certain aspect like criticality, severity, business impacts, or trends. This feature needs the separate app "Traffic-Lights for Jira Cloud"
(see https://marketplace.atlassian.com/apps/29738/traffic-lights-for-jira?tab=overview&hosting=cloud). ).